Are they
up? You'll
know first.

How often should you check your endpoints? It depends on what you'd lose during the gap. A 5-minute interval means you might learn about an outage 5 minutes after it starts — fine for a side project, painful for a checkout flow.

The math: if your worst-case downtime cost is $X per minute, your check interval should be far shorter than the time it takes you to lose $X. For most production apps, 30–60 seconds is the sweet spot. Sub-10-second checking sounds nice but mostly produces alert noise from transient blips.

The exception: anything customer-facing during peak hours — checkout, login, signup — deserves 30s checks even on hobby projects, because the cost of a missed outage is reputational, not just dollar-denominated.

Your API endpoint can return 200 OK while your database is dropping connections, your Redis cache has stalled, or your message queue is backed up. By the time HTTP requests start failing, users have been hitting timeouts for 5+ minutes.

The fix: monitor each tier independently. A direct PostgreSQL connection check tells you the database is reachable and responding. A Redis PING confirms cache health. Pair these with HTTP checks on your API and you'll see infrastructure problems before they become user-visible outages.

The classic anti-pattern: a /health endpoint that just returns {status: "ok"} without actually probing its dependencies. That endpoint is always the last thing to fail — not the first thing to warn you.

The fastest way to break trust is to mark something operational while customers are getting timeouts. Three rules:

1. Update within 10 minutes of detection. Silence after a known outage is worse than a partial update. "We're investigating reports of slow checkout" is fine — saying nothing is not.
2. Use plain language. "API is returning errors for 30% of requests" beats "investigating elevated 5xx response rates." Your users aren't on your incident channel.
3. Post the post-mortem. If you only update during incidents, your status page reads as a defensive document. If you publish summaries after every meaningful incident — even 4-minute ones — you build credibility that pays off when the big one hits.

The fastest way to train yourself to ignore alerts is to send 50 of them per week to the same Slack room. A channel-by-severity matrix that actually works:

• SEV1 — production down. Mobile push + Telegram + phone. You need to wake up.
• SEV2 — degraded, customer-impacting. Push + a Slack channel for team visibility.
• SEV3 — warnings, soft thresholds. Slack channel only. No push, ever.
• SEV4 — info, weekly-digest stuff. Email or dashboard. Never real-time.

The principle: the more disruptive the channel, the more critical the alert needs to be. A push notification at 3am should mean something is genuinely broken — not "response time is 50ms higher than usual."