Notes from the watchdog.

5 minutes of downtime costs more than you think

Most teams price downtime as the revenue lost while the checkout page is down. That number is almost always small, which is why monitoring budgets get cut. It's also the wrong number.

The real cost lands in three places that don't show up on an invoice: the support tickets that arrive before you even know anything is wrong, the trust spent with customers who assume your product is sloppy, and the engineer-hours burned diagnosing what a 30-second monitor would have told you in the first minute.

You never pay for downtime at the moment it happens. You pay for it over the following three months, in installments.

The fix is unglamorous: a monitor on every public URL, an alert channel that actually reaches a human, and a status page so the humans who noticed can see that you noticed too. That's the entire product pitch, and it fits in one sentence because the problem fits in one sentence.

Alert fatigue is a design problem

Every team that ignores its alerts has the same origin story: one month of genuine incidents, then a few false positives, then a slider somewhere in everyone's brain that mutes the channel. The alerts kept firing. The attention didn't.

Alert fatigue isn't caused by too many alerts. It's caused by alerts that didn't deserve to fire. A single failed request from one region isn't an incident; it's weather. Confirmation from multiple regions, a threshold held for sixty seconds, a recovery message that includes what actually happened — these small design choices are the difference between a channel people read and a channel people leave on mute.

The test is simple: if your on-call person can't explain why each of last week's alerts fired, the alerts are the bug.

Your status page is a product, not a courtesy

Most status pages are built the same way: a template bought after the first big outage, updated manually at the worst possible moment, by the engineer who should be fixing the thing. It shows.

A status page earns trust exactly when things are broken. Historical uptime that matches reality, incidents that open within a minute and get updates every fifteen, and a maintenance calendar — these tell your users something no marketing page can: that you know what's happening on your own infrastructure.

The teams that get this right treat the status page like a feature with an owner, not a document with a template. If it's on your domain, updated automatically, and tells the truth even when the truth is ugly, users read it. And users who read your status page file fewer tickets.