Most error dashboards report total error count, which is close to meaningless: it moves with traffic, with a single noisy bot, and with one bad third-party script. These are the numbers that actually tell you whether the product is working.
The standard mobile and front-end health metric is the percentage of sessions that completed without a crash or unhandled error. Track it per release. The useful property is that it is normalised by traffic, so it is comparable across days and versions, and it is the number you can regress-test a deploy against. Crash-free users is the harsher sibling: one user crashing in nine of ten sessions counts once, which surfaces problems concentrated in a specific device, locale or account type that session-level numbers average away.
What counts as good depends entirely on platform and complexity, so set your own baseline from your own last stable release rather than importing a number from a blog post. The signal is the delta, not the absolute.
Server-side, divide 5xx responses by total requests and split by code. 500 is your bug. 502 and 504 are an upstream's. 503 is deliberate load shedding. Alerting on a combined "5xx rate" mixes three different on-call responses into one page. Track 4xx separately as a product signal — a spike in 401s means an auth change broke clients, and a spike in 422s means a form is confusing or an integrator is misreading your docs.
Pick an availability target and derive the budget from it. A 99.9 percent monthly target allows roughly 43 minutes of downtime a month; 99.95 percent allows about 22; 99.99 percent allows about 4. That budget is a decision-making tool, not a report: while budget remains, ship features; when it is exhausted, the next sprint is reliability work. It converts an unwinnable argument about how much reliability is enough into arithmetic agreed in advance.
Median time from first occurrence to someone acknowledging it is the metric that exposes alerting gaps. If your users report issues before your monitoring does, that number is effectively infinite regardless of how good the dashboard looks. Track it alongside median time to resolution, and track the ratio — a team that resolves fast but detects slowly has a monitoring problem, not an engineering one.
Error tracking is billed per event, and one runaway loop can consume a month's quota in an afternoon. Sample transactions and performance traces aggressively — 1–10 percent is normal for high-traffic services — but keep error sampling at 100 percent, because the rare error is precisely the one you need. Configure rate limiting per issue rather than globally, and set up ignoreErrors for the known-junk categories: browser extension noise, ResizeObserver loop limit exceeded, and network errors from users going offline.
An error tracker's value depends almost entirely on whether it groups 10,000 occurrences into one issue or fragments them into 10,000. Fragmentation usually comes from dynamic values in the message — a user ID or a URL interpolated into the string. Put those in structured context fields and keep the message static. Without source maps uploaded per release, front-end stack traces are minified gibberish and grouping fails entirely, so make source map upload part of the deploy pipeline rather than a manual step.
Percentage of open issues that nobody has looked at in 30 days. An error tracker fills with unresolved noise faster than any other tool, and once the list is long enough that nobody reads it, the whole system is decorative. Either triage it or mute it deliberately — an ignored issue that you chose to ignore is fine; an ignored issue you never saw is a future incident.
Free tools, guides, and resources across the SPUNK13 network.
Visit spunk.bet400+ Free Tools