What can BugSnag show when a screen breaks?
Suppose a customer opens an appointment confirmation and the screen stops working while drawing the date. If your browser app reports the error, BugSnag can give you a code location to inspect and group related reports in its Inbox.
BugSnag calls one reported occurrence an event. Open the group, then look at an individual event for the code steps around the failure, called a stack trace. The report can point to the screen code without telling you whether the appointment is already saved. Check the booking itself separately.
What should stay out of a test report?
Use a separate test project and a local page that only displays a made-up appointment. Confirm the reporting destination. Keep booking, messaging and payment services disconnected from the page. If you cannot confirm those connections or access a test project, keep the exercise local.
The documented JavaScript library can add the page address and its query details, browser and device information, and short records of actions called breadcrumbs. Ask your developer to turn off automatic error detection, breadcrumbs, session reporting, client IP collection and the stored anonymous device identifier when setting up the library for this exercise. Check the exact library version and use its pre-send callback to strip unneeded details or block the report.
Before starting the library or triggering the error, have your developer direct reports to a receiver on your own computer with a dummy project key and block all outside sends. Use a fixed test error message, a made-up build label and a code location you are allowed to share. Keep entered fields, customer identifiers, credentials and URLs with private values out. If you replace BugSnag’s list of metadata keys to hide, include its default password protection in your own list. Inspect the actual report at the local receiver, including its message, addresses and anything your app adds. Fix any unexpected collection and check again locally before connecting the test project.
How do you check the alert reaches you?
Before sending to BugSnag, check everyone who can receive test-project notifications, including settings that apply across projects. Keep only test inboxes you control and turn off connected services that could receive or act on the report. If you cannot confirm every destination, keep the exercise local.
If your account offers project email notifications, choose the new-error rule for the test project and test environment in My email notifications. BugSnag checks whether the first event in that error group for the chosen environment matches your filters. A repeat in an already known group is a poor test of that rule. After the event arrives in the test project, check the inbox separately. If the email is missing, check the event’s group and environment, the recipient’s settings and the inbox before sending anything else.
How do you check one report and its version?
After the local report and notification destinations pass those checks, configure the React browser library for the empty test project. Before it starts, keep automatic errors and sessions off and add a pre-send check that allows only the deliberate practice error with the approved fields. Discard the report if it differs or the check fails.
- Set the environment and version explicitly in the browser configuration. A private URL alone does not mark the report as a test.
- If you use a bundled test build and want readable file names and line numbers, use the matching source map. Before uploading, review the code and paths it includes. Upload the map before the event, with the same app version and bundled file address the event will report. If BugSnag cannot fetch the bundled file, the upload can also include that file. Use only code you are allowed to send.
- After the local checks, use the practice page to cause one controlled error while it draws the invented date. Open its Inbox group and the individual event. Check the test project, environment, build and code location against the app that actually ran.
Can you tell whether an update made things better?
A build label helps you find reports from the version you changed. Repeat the appointment check with the corrected screen and comparable reporting settings. Confirm that the appointment details display as expected.
BugSnag documents stability features for Preferred and Enterprise. Session stability counts the share of recorded sessions without an unhandled error. Browser sessions can start when a page loads or the app changes its address. Rate-limited errors do not enter that score. Compare releases with similar collection settings. The practice exercise leaves session tracking off and checks a single screen outcome.
What does the hosted Free plan count?
BugSnag’s public Free plan lists $0 per month, one user, 7,500 error events and one million performance spans per month, with seven days of error event retention.
Count individual reports, including repeated events in a group. A span is a timed step used by the separate performance feature. The appointment test needs only the error report.
If your account limits collection and a report is rate-limited, BugSnag does not save it. An empty dashboard can leave a real failure unseen. Check your current plan, event usage and what happens to charges and collection at its limit before sending customer traffic. Check the order’s renewal and cancellation terms before choosing a paid plan.
What can you copy if you move to another tool?
BugSnag documents an authenticated way for another program to request the available events for an error. Check whether your plan and project permissions give you access before you rely on it.
Have your developer retrieve one permitted test event before depending on this for a move. Check which fields arrive and how far back the account can still read. Keep your app code and its checks separately. Exporting selected events leaves project rules, alert settings and expired history outside that export.