Errors, logs and performance monitoring Explained and Compared

How do you choose what to monitor in a web app?

Pick one action customers need to finish, such as signup or checkout. Decide how you will know it failed and what you would need to see before trying to fix it.

What should you look at when a customer says signup failed?

Start with what the person could not do and when they tried. Then choose the clue that answers the next question: an error report, a log entry, or a trace.

Choose a clue by what you need to find out
Question	Where to look	What it could show
Did a piece of code stop working?	An error report	The signup screen tried to use an email field before it was available.
Which step did the app reach?	Logs: notes the app writes as it works	The request arrived, the account was saved, and the confirmation message was never queued.
Where did the request spend its time?	A trace: a timeline for one request across connected parts	The signup page waited for the account service, which waited for the database.

On a small screen, scroll the table sideways to read every column.

How do you record your first error without sending customer data?

Use a test copy of your app and a made-up failure that cannot save a record, take a payment or send a customer a message. The goal is to see one useful clue and know exactly what the tool received.

Set up an isolated test
Use made-up accounts and test storage. Keep automatic reporting and screen recording off before you open the test app. Confirm which private test project will receive the example and who can see it. Turn off any alerts or connected services that could send the report somewhere else.
See what the app would send
Try a deliberate failure such as a test button that stops before saving a signup. Capture the report only on your own computer. Look for the time, the failed step and a made-up label you can search for, such as “practice-one”. Inspect web addresses, error details and anything attached automatically. Remove passwords, access keys, session cookies and form contents before any send. Hiding a field in a search does not remove it from the stored report.
Find the report in the test project
Send only the practice report once you can confirm its fields and every destination. Keep it on your computer if you cannot confirm either. Search by the made-up label or by time and open the report. Can you tell which step stopped without seeing what the customer typed?
Confirm what happened and remove the test
Check that the intended report arrived once, no unexpected information appeared, and no signup or message was created. Remove the deliberate failure before the app sees real customers.

Compare tools

Scroll the table sideways to read every column.

Compare how tools help you investigate a failure
Tool	First clueWhat you can expect to look for when something goes wrong.	What your app must sendWhat needs to be connected before the clue appears.	What to check before sendingWhere the test setup can prevent private information from leaving your app.	What runs outWhat is counted or kept, and which setting to check.	What can you copy?A documented way to take some evidence with you.
Sentry	Grouped reports of errors that your app sends.	Connect the relevant app code and verify the report points to a useful source line. Check release tracking separately.	Inspect a harmless test report for fields the browser or server setup attaches.	The hosted Developer plan counts individual error events. Later reports may stop appearing when the relevant quota is exhausted.	Sentry lists API access on Team and higher hosted plans. The API lets another program request an issue’s available error reports.
Axiom	Search the log entries your app or hosting service has sent.	Connect a log sender for each service you need to investigate. Include a safe shared attempt label if you want to find its steps together.	Choose fields before forwarding. Hiding a field in a search leaves the stored event unchanged.	Incoming data, searching and how much history you keep have separate limits or charges.	Download selected query results as a spreadsheet-friendly CSV file or structured JSON for another program.
Honeycomb	Follow the parts of one slow request on a timeline. Missing steps leave gaps in the picture.	Connect each service you need to see and verify that two connected steps appear in one test trace.	Check the measured fields and information passed between test services before forwarding the trace.	One request can count as several events. Received spans and extra span events or links each count.	Export query results in the interface. Enterprise can return more summary rows when results split by time are turned off. Each API query covers up to seven days.
Better Stack	Search notes from the website and the part of the app that does work in the background.	Connect each intended log source and use one safe label to find the notes for an attempt.	Inspect what the app actually sends before enabling a broad log connection.	Log intake and searchable storage have separate rates. Check the plan and data region.	Save selected records as structured JSON. The read-only connection can still read all sources in each team it covers.
BugSnag	Open one grouped browser error and see the location or version reported by the app.	Connect the browser library. Verify the version label and upload the matching source map if the reported code location needs translating.	Turn off automatic reports for the practice setup, allow only the checked example, and confirm everyone and everything that can receive it.	The hosted Free plan lists 7,500 error events per month, a separate allowance for performance measurements, and seven days of error-event history.	Request the available events for an error. Check that your plan and project permissions let you use the interface.
Rollbar	Open one grouped error and inspect a specific report, called an occurrence.	Connect browser reporting. Have your release process tell Rollbar about the version. Verify any source map against the exact browser file.	Inspect the fields locally before enabling reporting. Use only test storage and confirmed notification destinations for practice.	Individual error reports count even when grouped. The hosted Free plan keeps up to 30 days of individual report detail.	Retrieve the project’s retained occurrences in pages with a credential that has read access.

Which failure should send you a message?

Pick a failure where you can take a useful action soon, such as repeated unsuccessful signups. Decide who should receive the message and what they should check first.

Reuse the isolated test copy and point the alert to a test destination you control. Confirm the rule starts without an active alert. Then cause a made-up failure that matches the rule. For a scheduled rule set to three failures in five minutes, send three made-up failures in that period and wait for the next check. For a rule that responds to individual events, send one matching example.

Confirm the message arrives and says what to check next. If your rule sends a recovery notice, check how it behaves after failures stop. Choose real thresholds from your traffic and what your team can respond to. A single high-impact failure may deserve different treatment from a brief rise in routine errors.

How do you know a fix actually helped?

Repeat the test that failed and check the customer outcome. After releasing the fix, compare the share of attempts that fail over similar time periods.

Evidence to check before and after a fix
Check	What to compare
The actual task	Can a disposable user finish signup and see the expected next screen?
Failures out of attempts	Ten failures out of one hundred attempts is different from ten out of ten thousand. Use the same definition of an attempt both times.
What the tool can still see	Check that new data is arriving and that any limits or recording settings did not change. A quieter chart is not enough to show a fix worked.

What can get more expensive or disappear as your app grows?

Check the unit on your plan and how long the tool keeps each kind of evidence. A count of error reports, a gigabyte of logs and a week of saved history measure different things.

Estimate a busy day as well as a normal one. Check whether a limit can stop collection, shorten the period you can search or create a charge. Try downloading a small allowed set of test records. Confirm which fields and time ranges you can retrieve and whether saved searches and alerts need rebuilding elsewhere.

When is it useful to add traces or recordings?

Add a trace when you repeatedly need to know where a request waited or stopped across several parts of your app. Consider a screen recording only if you need a visual clue that safer test evidence cannot give you.

A trace can join timed steps only where the relevant parts are connected and report them. Check one complete test request before relying on it. Recording more can capture more private information. Decide what needs to stay hidden, who should have access and whether a screenshot made with test data already answers the question.