A visitor taps Create account and sees a blank screen. If your app reports the failure, Sentry can show which part of the code was running when it broke and group later reports of a similar error.

An event is one error report. Sentry groups related events into an issue so you can work through one problem at a time. A stack trace is the trail of code steps that led to the error. Use it to find a likely starting point, then reproduce the signup problem and check whether your fix works.

Choose the evidence that answers your first question
What you see	What to check first
The signup screen goes blank	Look for an error from the browser, where the screen runs.
The screen stays open but the account is not created	Check the server that handles signups. If it reports a failure, open that event.
The app rejects an email already in use	Check whether this is an expected result that your screen should explain. It does not have to produce an error report.

What should you keep out before sending error reports?

Start with a separate test project and made-up data. Before connecting real traffic, check what your app sends so names, email addresses, passwords, cookies, access tokens and form contents stay out of reports.

An SDK is the small software library that sends reports from your app. Ask your coding agent or developer to check the settings for the exact version you installed and for both the browser and server where relevant. Sentry’s documented browser HTTP error integration does not attach full request or response contents. Some server integrations can attach incoming request contents. In JavaScript SDK 10.57.0 or later, the documented setting can turn off automatic body collection across supported cases. Check your runtime and leave these contents out of anything you attach yourself.

Turning off full contents is one check. Review URLs, error messages, headers, screenshots and any other features you turn on separately. Start without recording a person’s screen or session. Use your test copy to inspect what the receiver actually gets before turning the connection on for customers.

How do you get a first error report you can act on?

Send one harmless test error from the part of the app you want to monitor. In Sentry, check that it reached the test project and shows a useful code location.

Before running the test, confirm that the app uses test records and cannot create a real account, send a real message or start paid work. If you cannot confirm those connections, use a stand-alone error test that never calls them.
Label the test environment and, if you need to compare versions, send the release label that identifies the exact code running.
When a browser report shows shortened or bundled code, have your developer connect the source maps for that exact build. A source map lets a report point back to the original file and line. Upload the matching files before sending the test error; later uploads do not reprocess older errors.
Open the test event. Confirm the environment, code location and approved fields. Fix the test or setup and repeat with made-up data before changing how customer traffic is monitored.

How do you know an alert will reach you?

Choose one important project and an alert that matches a new signup error. Route it to a test destination you control first and confirm it actually arrives.

A test notification checks the delivery route. An actual synthetic error checks whether your project, environment and alert condition match. A new-issue alert runs when an issue is first created; repeated reports for that issue do not create a second new issue. For a frequency rule, send enough made-up events to meet its condition within the rule’s window and check both the alert history and delivery.

What counts toward the plan, and what happens if you run out?

Sentry’s hosted Developer plan is free and lists 5,000 error events per monthly usage period. Count the individual reports: many repeated errors can still use capacity even when Sentry groups them into one issue.

Check these before turning up reporting
What to check	Why it matters
Error events accepted in the current billing period	A bug that repeats can use the allowance quickly. Projects in the same Sentry organization share that quota, including a separate test project. Free Developer accounts have no on-demand spending option.
Any separate features you turn on	Logs, recordings of user sessions and timing information have separate measurements. Check their current terms independently.
What happens at the limit	Reports dropped when the quota is exhausted cannot be retrieved later by adding capacity. Keep another way to check whether your signup still works.

What can you take with you if you switch tools?

Sentry lists API access on Team and higher hosted plans. The API lets another program request records. With permission to read events, it can retrieve the available error reports for one issue. Decide which records you actually need before changing tools.

For example, have your developer retrieve one permitted test event and check which details arrive. That proves what that retrieval includes. Do not assume it copies every historical report, alert rule or project setting. Check access and retention for the data you depend on, and keep your app code and test checks in a place you control.