Rollbar

What can one browser error tell you?

Imagine the Save draft button stops working after an update. The exercise below uses a test copy with a made-up error called “Practice draft save failed.” Rollbar puts reports it groups together under one item. Open the item and select an occurrence, meaning one report, to see what the app sent for that attempt.

Look for the time, the test copy’s version and the code path, which lists the functions running when the error occurred. If the browser is the only part you connected, look separately for what happened on the server, the part of the app that handles the save. After a fix, repeat the task with the isolated test setup below and check that you can reopen the saved draft from test storage. If you only ran the local error example, wait until you have an isolated save path before checking the fix.

How do you inspect a test report before sending it?

Use a test copy with made-up records. Before clicking Save draft, have your developer check that it writes only to test storage and cannot trigger live messages or other actions. If you cannot confirm that, use a local practice button that creates the sample error without saving anything. Ask your developer to add Rollbar’s browser reporting library and have it deliberately report the practice error. Leave automatic error collection, notes about browsing activity and session recording off during this check.

First direct the test library to a receiver on your own computer with a dummy token, and block the test app from sending reports to outside addresses. Inspect the actual report your browser would send. Check that it contains only the details you approved, such as the error name, code path, test environment and build version. Look for unexpected page addresses, typed values, account details, access keys and IP addresses. Fix any unwanted collection and inspect a fresh report before connecting the hosted project.

Use a separate Rollbar project for the hosted check. Before you send any release notice or error, check all enabled notification rules and continue only if they reach a test inbox you control. Give the browser only the token that can send browser reports to that project. Keep tokens that read reports, report releases or upload source maps in protected settings outside the browser.

How do you connect the error to a release?

A release is a specific version of your app that you put online. Have your developer report the test copy’s release to Rollbar from the system that publishes it. Rollbar’s Deploy Tracking needs that explicit notice.

Send the same version label and environment name in the release notice and the browser report. If your project uses Git, use the identifier for the saved code change that built the test copy. Open the release history and the individual error report and confirm that the version matches.

If Rollbar shows a suspect release, use it as a starting point. It looks at the last reported release before the issue appeared or came back. Try the same task on comparable versions before deciding what caused the failure.

How do you check that one alert reaches you?

Before the first practice error arrives in Rollbar, set a New Item email rule for the test environment. Point it to the inbox you reserved for the exercise.

Send the previously unseen practice error and confirm that Rollbar opens a new item. Then verify that the matching email arrives in the intended inbox. If the item appears but the email is missing, check the rule’s filter and recipient separately. Remove the temporary rule after the exercise.

What does Rollbar count and how long does it keep the details?

Rollbar prices error monitoring by report volume. Several reports grouped under one item still use several occurrences. Session recordings have their own allowance.

During a spike, a sender can hit a short-term rate limit even when you are below your monthly plan allowance. Reports rejected by the rate limit do not appear in the project. If reports suddenly go quiet, check whether sending is limited and repeat the affected task before deciding it is fixed. Paid retention and limits depend on the plan and settings.

When do you need a source map?

If the report points to a shortened file that is hard to read, a source map can connect that file back to the original line of code. Ask your developer to enable browser source mapping and upload the map for the exact file the test copy serves.

For an uploaded map, the version in the browser report has to match the map’s version. Maps may contain original source code. Check what the file includes before sharing it with Rollbar, and upload it from protected settings rather than putting the upload token in the page. Upload before recreating the test error. Open the new occurrence and confirm that it points to the expected original line.

What error history can you take with you?

A developer can use Rollbar’s API, the interface programs use to ask for data, to retrieve retained error records from a project. The occurrence listing returns the records in pages. Use a project token with read access and keep it out of the browser.

Start with one known practice report. Confirm that the exported data contains the fields you need, store it where only the right people can read it, and export before the project’s retention period ends. Make a separate checklist for any alert rules, release history or recordings you would need to carry over. The occurrence export is the evidence path for retained error records.