Uptime monitoring explained (and how to set it up)
Uptime monitoring explained simply: what to check, how often, which signals matter, and how to get alerted the moment your app goes down — not after.
Your app can be "up" and still broken. The server responds, the load balancer is green, and yet checkout returns a 500 for everyone. That gap — between "the box is on" and "the thing customers need actually works" — is what good uptime monitoring is really about. This post explains what uptime monitoring is, what to check, and how to set it up so you hear about an outage the moment it starts, instead of from a customer an hour later.
What uptime monitoring actually is
At its simplest, uptime monitoring is an outside service that asks your app "are you there?" on a schedule and records the answer. Every minute or so it makes a request and checks: did it respond, how fast, and was the response what you expected?
The key word is outside. Monitoring your app from your own server tells you nothing when that server is the thing that is down. A real uptime check runs somewhere else and sees your app the way a user does — over the public internet.
Check the right thing, not just the homepage
Pinging / and getting a 200 is the weakest possible check. Your homepage can be served from cache while your database is on fire. Better targets:
- A health endpoint that actually touches your critical dependencies (database, cache, queue) and returns a real status
- A user-critical path — the login page, the API root, the checkout endpoint
- Content assertions — not just "200 OK" but "the response contains the word we expect"
A check that verifies real behavior catches the outages that a homepage ping sleeps through.
The signals that matter
A good uptime check produces more than up/down. Watch:
- Availability — the percentage of checks that succeeded over a window
- Response time — slow is the early warning before down; a creeping latency trend often precedes an outage
- Status code — a 500 and a 503 mean different things; capture which
- From multiple locations — one failing region can be a network blip, not your outage
Together these tell you not just that something is wrong but how wrong and how widespread.
How often to check
Frequency is a trade-off between speed and noise. Every minute is a sensible default for production: fast enough that you learn about an outage within a minute or two, slow enough that you are not hammering your own app. For less critical endpoints, every five minutes is fine. Whatever you pick, require two consecutive failures before alerting so a single dropped packet does not page you at 3 a.m.
Set it up and get alerted
The setup is the easy part — the value is in the alerting. With Lookout, uptime checks live alongside your errors, queues, and logs, so a downtime alert reaches the same Email or Slack channel as everything else and you are not juggling five tools. Connect your app over plain HTTP/JSON with two commands:
composer require lookout/tracing
php artisan lookout:install
LOOKOUT_LARAVEL=true
LOOKOUT_API_KEY=your-project-api-key
LOOKOUT_URL=https://your-lookout-host.example.com
Point a check at a real health endpoint, set the cadence, and add an alert rule. When the endpoint fails twice in a row, the right person hears about it — once — instead of the whole team getting paged on every blip.
Pair uptime with error tracking
Uptime monitoring tells you that something is down; error tracking tells you why. On their own, each leaves you guessing. Together, a downtime alert arrives next to the exception that caused it, and your investigation starts with a lead instead of a blank terminal.
That combination is the point of putting them in one place. Lookout's free Starter tier (10,000 events a month, one project, no credit card) is enough to put an uptime check on your most important endpoint and wire the alert today. Set up uptime monitoring for free and find out before your customers do.