There's a class of outage that produces zero errors in your error tracker — and it's one of the most common ways a site goes down. DNS breaks, the CDN edge fails, a third-party API goes offline, your deploy didn't ship the new bundle, or the error tracker's own ingest endpoint is unreachable. In every one of these cases your application throws no exception, your Sentry/Rollbar/Bugsnag dashboard shows a flat line of zero new errors, and the on-call engineer concludes "everything looks healthy" while users stare at a blank page. Error monitoring and uptime monitoring answer two different questions, and running only one of them is a structural blind spot.
Error monitoring tells you when your code is throwing exceptions. Uptime monitoring tells you when users can't reach or use your site. They look overlapping from a distance, but they catch completely different failure modes. This guide explains what each one sees, where each one is blind, and why mature teams run both — including the case where the error tracker itself is the thing that's down.
What error monitoring is
Error monitoring (also called error tracking) is the continuous capture, grouping, and alerting over application exceptions. Tools like Sentry, Rollbar, Bugsnag, and Crashlytics instrument your code so that when an exception fires — a thrown error, an unhandled promise rejection, a crash — the event is captured with its stack trace, request context, user context, and release tag, then grouped with similar events into an "issue" you can triage.
What error tracking is genuinely great at:
- Code exceptions with full context. The exact file, line, and stack frame that threw, plus the request and user that triggered it.
- Release regression detection. "Errors from release
v2.4.1spiked 10x" — catching a bad deploy before it spreads. See CI/CD pipeline monitoring. - Crash rate and release health. Mobile and desktop apps use error tracking to measure crash-free sessions per release.
- Client-side JavaScript errors. Errors that happen in the browser — a broken checkout button, a React render crash — that your server never sees.
- Grouping noise away. A thousand identical exceptions become one issue with a count, not a thousand alerts.
Error tracking is the default tool for "my code is misbehaving." For the 4xx client errors and 5xx server errors that surface as exceptions, it's the right layer.
The "no errors but site is down" failure mode
Here's the structural problem with relying on error tracking alone: an error tracker only records an event when your code throws an exception that reaches the tracker. A large fraction of real outages never produce such an event, because the failure happens before your code runs or outside your application boundary:
- Total outage. The server is down, the container is crash-looping, the load balancer has no healthy targets. No requests reach the app, so no exceptions fire, so the error tracker records nothing. A flat error rate looks like health.
- DNS and routing failures. No request resolves to your origin, so no application code executes. See DNS propagation monitoring.
- CDN and edge failures. A Cloudflare 520 error page is served to the user from the edge; your origin never sees the request and logs no error. See Cloudflare monitoring.
- Third-party API outages. If Stripe is down and your integration degrades gracefully (shows "payment unavailable" instead of throwing), no exception fires — but checkout is broken for every user. See third-party API monitoring.
- Static asset and bundle failures. A deploy that shipped a broken JS bundle produces a white screen for users; the error happens in the browser and may or may not reach your tracker depending on instrumentation.
- The error tracker itself going down. If Sentry's ingest endpoint is unreachable from your servers, your exceptions silently stop being recorded. Your dashboard goes flat — indistinguishable from "no errors." This is the error-tracking equivalent of the silent log shipper, and it happens more than vendors admit.
The pattern in every case: absence of errors is not presence of health. Error tracking is an inside-out signal that depends on your code running and reaching the tracker. Uptime monitoring is an outside-in signal that depends on nothing but the user's perspective.
What uptime monitoring catches that error tracking can't
Uptime monitoring probes your site the way a user would — from outside your infrastructure, on a schedule, asserting that the right thing happens. It catches the entire class of "no errors but broken" failures:
- Is the site reachable at all? A
GET /that returns 200 from multiple regions catches total outages, DNS failures, and CDN edge failures. See multi-region monitoring. - Is the critical path working? A multi-step monitor that walks login → search → checkout catches functional breakage that throws no exception (a checkout that returns 200 but renders the wrong page). This is the single most valuable complement to error tracking.
- Is it fast enough? Response-time and TTFB alerts catch the "200 but 12 seconds" case that error tracking is blind to. See latency percentiles.
- Are dependencies up? Your payment, auth, and email APIs probed directly — see third-party API monitoring.
- Is the error tracker itself up? Monitoring the Sentry/Rollbar ingest endpoint as a dependency tells you when your error tracking has gone dark. See monitoring authenticated APIs.
- Are config and content intact? SSL expiry,
robots.txtchanges, schema drops — see SEO health monitoring and content change detection.
None of these produce an exception in your application code, so none of them will ever surface in error tracking alone.
What error tracking catches that uptime monitoring can't
The reverse is also true. Uptime monitoring can't tell you why something broke, only that it broke. Error tracking owns the diagnosis layer:
- The stack trace and root cause. Uptime tells you checkout is returning 500; error tracking tells you it's a null pointer in
calculate_tax()on line 142. - Client-side errors that don't break the page. A broken analytics call, a non-critical widget that throws — these hurt UX and data but don't trip an uptime check.
- Release attribution. "This regression started with
v2.4.1" is an error-tracking insight; uptime monitoring only sees the symptom. - Error grouping and triage. Thousands of identical exceptions become one issue to fix, with affected-user counts and breadcrumbs.
This is why the two are complements, not alternatives. Uptime monitoring is your alarm that something is broken for users; error tracking is your microscope for what in the code caused it.
How to run both without the noise
Pairing the two is straightforward in principle and requires discipline in practice:
- Page on outside-in, triage with inside-out. Uptime monitoring should be your paging source for user-visible outages (it's the signal that users are affected). Error tracking is your triage source once you know something's wrong. Inverting this — paging on every error spike — causes alert fatigue, because most error spikes are handled by retries or affect no real user.
- Correlate, don't duplicate. When uptime fires "checkout 500," the incident view should pull the corresponding error-tracking issues for that release and time window. Treat the two as layers of one incident, not separate alerts.
- Watch for the "healthy silence" trap. If error tracking goes flat and traffic is normal, suspect the error tracker, not the code. Monitoring the ingest endpoint catches this.
- Suppress one during the other's declared incident. Once you've declared an incident, suppress the duplicate cascade from whichever layer is noisier. See alert flapping detection.
- Define severity by user impact, not error count. A 0% error rate with the site down is a Sev-1; a 5% error rate with full recovery and no user impact is a Sev-3. See incident severity levels.
How Webalert Helps
Webalert is the outside-in half of the pair — the alarm that catches everything error tracking can't:
- Multi-region uptime and API monitoring catches total outages, DNS, CDN edge, and routing failures — the entire "no errors but down" class.
- Multi-step monitors with assertions walk the critical path (login, search, checkout) and catch functional breakage that throws no exception. Pair this with error tracking and you've covered both "is it up" and "is it broken in code."
- Response-time and TTFB alerts catch the slow-but-200 case.
- Monitor your error tracker as a dependency. Probe the Sentry/Rollbar/Bugsnag ingest endpoint with authenticated API monitoring so you know the moment your error tracking goes dark — and a flat error dashboard never fools you into thinking the site is healthy.
- Content change detection and SEO health monitoring catch the config and content failures that produce no exceptions.
- Status page and incident management to correlate the uptime alarm with the error-tracking triage in one place, and write a clean post-mortem afterward.
Webalert won't capture your stack traces — that's error tracking's job. But Webalert will tell you the moment your site is failing for users in a way your error tracker will never see, and confirm the moment it's recovered.
Summary
Error monitoring (Sentry, Rollbar, Bugsnag) captures code exceptions with full context and is the best tool for diagnosing why your code broke. Its structural blind spot is that it only records events when your code throws an exception that reaches the tracker — so total outages, DNS failures, CDN edge errors, third-party API outages, broken deploys, and the failure of the error tracker itself all produce zero errors and look identical to "healthy." Uptime monitoring is the outside-in complement that catches every "no errors but down" failure by probing the site the way a user would. Run both: page on outside-in uptime (the signal that users are affected), triage with inside-out error tracking (the signal of what in the code caused it), watch for the "healthy silence" trap by monitoring the error tracker's own ingest endpoint, and define severity by user impact rather than error count.
Error and uptime monitoring checklist
- Error tracker (Sentry/Rollbar/Bugsnag) instrumented on backend and frontend
- Release tags on every deploy so regressions are attributable
- Outside-in uptime monitoring on homepage and critical path from multiple regions
- Multi-step monitor walking login/search/checkout with assertions at each step
- Response-time and TTFB alerts at p95 thresholds
- Error tracker ingest endpoint monitored as an external dependency
- Paging routed from uptime monitoring (user impact), not from every error spike
- Incident view correlates uptime alarm with error-tracking issues for the same window
- Duplicate alerts suppressed during declared incidents
- Severity defined by user impact, not raw error count
- Third-party dependencies (payments, auth, email) probed directly
Frequently Asked Questions
What is the difference between error monitoring and uptime monitoring?
Error monitoring (Sentry, Rollbar, Bugsnag) captures code exceptions with stack traces and context — it tells you why your code broke. Uptime monitoring probes your site from outside your infrastructure the way a user would — it tells you whether users can reach and use your site. Error monitoring is inside-out and depends on your code running; uptime monitoring is outside-in and depends on nothing but the user's perspective.
Can error monitoring detect when my website is down?
Not reliably. A total outage produces no requests to your application, so no exceptions fire, so your error tracker records nothing — a flat error rate that looks like health. DNS failures, CDN edge errors, third-party API outages, and the failure of the error tracker itself all produce zero errors too. "No errors" is not the same as "site is up." You need outside-in uptime monitoring to detect these.
Do I need uptime monitoring if I already have Sentry?
Yes. Sentry catches code exceptions; it cannot catch the outages that produce no exceptions — total outages, DNS, CDN edge, third-party API outages, broken deploys, and the case where Sentry's own ingest endpoint is unreachable. Pair Sentry with outside-in uptime monitoring so a flat error dashboard never gets mistaken for a healthy site.
Should I page on error spikes or on uptime alerts?
Page on uptime alerts, triage with error tracking. Uptime monitoring is the signal that users are actually affected; error spikes are often handled by retries or affect no real user, and paging on every spike causes alert fatigue. Use error tracking to diagnose once uptime monitoring has told you something is broken for users.