Uptime Checks, Synthetic Monitoring, and Error Tracking Are Three Products

These three products share a shelf, a pricing page aesthetic, and a promise: you will find out when something breaks. They are not substitutes. An uptime check tells you the door is unlocked. Synthetic monitoring tells you whether a customer can walk in, find the thing, and pay. Error tracking tells you the ceiling fell in.

Buying the wrong one is not a wasted subscription. It is a specific, predictable blindness that you discover at the worst possible time, usually because a customer tells you first.

What each one actually answers

The billing columns are where small teams get hurt, and they are not comparable to each other. A monitor that runs every sixty seconds is a fixed, predictable cost. Error tracking is metered by volume, which means it is priced by how badly your code is misbehaving — the bill and the incident arrive together.

The green dashboard that hid a broken checkout

A concrete case. A checkout endpoint validates a cart, calls a payment provider, and returns JSON. The handler catches every exception, logs it, and returns HTTP 200 with {"ok": false}. This is a common pattern and it is not unreasonable; the developer did not want the client to see a stack trace.

The uptime monitor is pointed at /health, which pings the database and returns 200. It is green. The dashboard is green. The payment provider's status page is green. Customers are seeing "payment could not be processed" and emailing support.

Nothing in the stack was lying. The uptime check answered its question correctly: the server was up. The failure was inside a 200 response, which is exactly the class of failure uptime checks cannot see by design.

A synthetic monitor running the checkout flow with a test card would have caught it in one run, because it asserts on the outcome rather than the status code. Error tracking would have caught it only if the handler had re-thrown or reported to the tracker instead of swallowing — and swallowed exceptions are precisely the ones people forget to instrument.

The first monitoring decision is not which vendor. It is which failure you are most afraid of, because each product only sees its own.

Alert arithmetic, and why you stop reading them

A check running every sixty seconds executes 1,440 times a day, or about 43,200 times a month. Suppose 0.4 percent of those runs fail transiently — a network blip from the probe's location, a deploy that restarts the process, a slow query during a backup. That is 172 alerts a month, roughly six a day.

At six alerts a day, nobody reads them. Not because the team is careless, but because the human response to a signal that is wrong most of the time is to stop treating it as a signal. The failure is not the alerting tool; it is the missing confirmation step.

Three settings fix most of it. Require three consecutive failures before alerting, which turns a sixty-second blip into a three-minute condition. Confirm from a second location so a single probe's routing problem does not page anyone. And separate warning from page: a single failed check writes to a channel, three failures across two regions wakes someone up.

Run the same arithmetic on error tracking. If a retry loop throws on every attempt, one bad deploy can emit hundreds of thousands of events before anyone looks, and per-event billing means the incident generates an invoice. Rate limits per issue and inbound filters for known-noise errors are not advanced features; they are the difference between a bill you can predict and one you cannot.

A dashboard is not monitoring

Grafana will draw anything, over any data source, and that is its virtue and its trap. A dashboard is a pull product: it shows you the truth when a human chooses to look. Monitoring is a push product: it tells you when you are not looking.

Teams routinely build an excellent dashboard, feel monitored, and then learn about a three-hour outage from a customer. The dashboard was correct the whole time.

The honest use for a dashboard is investigation, not detection. Once an alert fires, the dashboard answers "how long, how bad, what else moved." That is a real job and worth the setup. It is just not the job people buy it for.

Product analytics belongs in the same category, with one genuinely useful monitoring application: it can tell you that conversion fell twelve percent at 14:20, which is often the only signal you get when a change breaks something without throwing. It will not tell you why. Treat it as the smoke detector for revenue, not the fire investigation.

The order to buy them in

Uptime first, because it is the cheapest and it catches the failure that costs the most per minute: total unavailability. Two or three checks are enough — your marketing site, your API, and your login. Point them at endpoints that actually exercise a dependency, not a static file that a CDN will serve from cache while your database is on fire.

Error tracking second, because for a team that ships weekly it has the highest diagnostic value per dollar. The first thing it buys is not alerts but grouping: knowing that four thousand errors are one bug rather than four thousand problems changes how you triage. Set a release tag from the start, or you will spend the first incident guessing which deploy caused it.

Synthetic third, and only when a flow is directly revenue-bearing and someone will maintain the script. A synthetic test is code. Code rots when the login page changes, and a broken test that fails every run is worse than no test, because it trains the team to ignore that channel too.

There is a fourth option that people reach for too early: self-hosted dashboards and alerting on top of your own metrics. It is cheap in license terms and expensive in attention, because you now own the uptime of the thing that tells you about uptime. If the monitoring server shares a host or a network with the application, the first thing a serious outage takes down is your ability to see it. Whatever you run, the checker has to live somewhere the failure does not reach.

What to instrument before you buy anything

Three things, all free. Make every endpoint that can fail return a non-200 status, or at minimum include a machine-readable success flag that your checks assert on. Log a request ID and return it in the error response, so a support email can be traced to a log line. And make sure your health check distinguishes "process is alive" from "dependencies are reachable," because the first one is nearly always true and therefore nearly useless.

That work takes an afternoon and improves every product on this list. Buying error tracking to compensate for swallowed exceptions is buying a louder smoke alarm for a room with no windows.

Rule of thumb: alert on what a user would notice, not on what you can measure. If an alert's required action is "go and look," delete it. If it has no owner, it will be muted within a fortnight, and the mute will outlive whoever set it.