We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Observability Monitoring
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Observability Monitoring
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You've seen them. Status.github.com, status.aws.amazon.com, status.slack.com. Every major service has a status page that shows green checkmarks and proclaims "All Systems Operational", often while your own experience is clearly broken.
The reason these pages are sometimes wrong is that uptime monitoring is harder than it looks. Checking whether a server responds to a ping is trivial. Checking whether your users can actually complete a checkout, load a dashboard, or send a message is a different problem entirely.
Uptime monitoring is the most fundamental piece of observability. Before you measure response times, track errors, or analyze logs, you need to answer one question: is this thing on?
At its simplest, uptime monitoring sends a request to your service at regular intervals and checks whether it gets a valid response.
| Check Type | What It Does | Catches | Misses |
|---|---|---|---|
| Ping (ICMP) | Sends a tiny packet, checks for response | Server completely down, network unreachable | Application crashes, slow responses |
| check | Sends an HTTP request, checks for 200 OK | Server down, application errors returning 500 | Partial failures, downstream dependency issues |
| Health endpoint | Hits a custom /health route that checks dependencies | App down, database disconnected, cache unavailable | Subtle degradation, intermittent issues |
| Synthetic transaction | Runs a real user flow (login, search, checkout) | Everything above + broken business logic | Extremely intermittent or region-specific issues |
Each layer catches problems the previous one misses. Ping tells you the machine is on. HTTP tells you the web server is running. Health endpoints tell you the application and its dependencies are functioning. Synthetic transactions tell you the user experience actually works.
Most teams run checks every 30-60 seconds from multiple geographic locations. If a check fails from one location, it might be a network blip. If it fails from three locations simultaneously, you've got an incident.