Website monitoring service that checks it’s really down before it wakes you up
StatusEagle checks your site from 3 locations as often as every 60 seconds: availability, response time, page content, SSL certificate and domain expiry, and confirms each failure from more than one location before alerting.
Verified check · Live multi-region test
What website monitoring checks
A site can fail in ways that a simple “is it up?” ping never sees. Useful website monitoring covers five failure modes:
In StatusEagle, one website monitor covers availability, response time, SSL and domain expiry together. Keyword checks are a separate monitor type because they target a specific string on a specific page.
| Failure | What you’d see |
|---|---|
| Timeout, connection refused, 5xx | HTTP/HTTPS status validation |
| Pages load, but TTFB climbs from 200 ms to 3 s | Response-time tracking with thresholds |
| HTTP 200, but a blank page or an error template | Keyword monitoring (plain, case-sensitive or regex) |
| Browser security warning; API clients refuse to connect | SSL expiry, issuer and validity |
| Site and email disappear when registration lapses | WHOIS domain expiry |
How StatusEagle monitors a website
Choosing a check interval
Monitoring is sampling. The interval sets two things: how long an outage can run before you know, and how short an outage can be and still go unseen.
Use 60-second checks for checkout, login and public APIs; 5-minute checks are fine for documentation or marketing pages. To see what an uptime target allows in practice:
Based on an average month of 30.44 days and a year of 365.25 days.
| Availability | Downtime / month | Downtime / year |
|---|---|---|
| 7 h 18 m | 3 d 15 h 40 m | Internal tools, side projects |
| 3 h 39 m | 1 d 19 h 50 m | Marketing sites |
| 43 m 50 s | 8 h 46 m | Most SaaS SLAs |
| 21 m 55 s | 4 h 23 m | Payments, checkout, core APIs |
| 4 m 23 s | 52 m 36 s | Infrastructure providers |
Why false alerts happen, and how verification stops them
Most false “down” alerts come from the path between the monitor and your server, not from your server: packet loss at one provider, a DNS resolver timing out, a TLS handshake stalling under load. They clear on their own within seconds.
StatusEagle doesn’t alert on the first failure. It retries from the same location, then checks from its other locations. A failure that doesn’t reproduce is logged but not paged. The trade-off is a few seconds of added detection time, which you can reduce by lowering the retry count on a monitor.
Set up your first monitor
A starting set of monitors for a typical site
Here’s the set we’d set up first for an online store or SaaS app with a marketing site, an app and an API. It uses 10 monitors, so it fits on the Free plan. Upgrade when you need 60-second checks on the pages that make money.
Swap in your own URLs. The principle is to monitor each system a customer passes through, not only the page they land on.
| What | Monitor type | Pass condition | Why it’s there |
|---|---|---|---|
| https://example.com/ | Website | 200 | Homepage, SSL and domain expiry in one monitor |
| http://example.com/ | Website | 301 | Proves the HTTP → HTTPS redirect still works |
| /pricing or /product/best-seller | Keyword | Price text present | Catches “200 but empty” pages when the CMS or database fails |
| /login | Website | 200 | Often served by a different service than the homepage |
| /checkout or /signup | Keyword | “Something went wrong” absent | Revenue path; error templates often return 200 |
| api.example.com/health | Website | 200, with auth header | The API the frontend depends on, monitored separately |
| app.example.com | Website | 200 or 302 | Apps often redirect to login; expect that, not 200 |
| mail.example.com:587 | Port | Open | Password resets and receipts depend on outbound mail |
| example.net (defensive domain) | Domain | > 30 days to expiry | Redirect-only domains get forgotten until they lapse |
| Nightly sitemap / feed job | Cron heartbeat | Pinged daily | Stale sitemaps and product feeds fail without an error page |
https://example.com/
Pick the right expected status code
A monitor that expects 200 everywhere will either miss problems or cry wolf. Set the code the endpoint should return when it’s healthy:
Not sure what a code means? Our HTTP status code reference explains each one.
Reading response time without fooling yourself
Averages hide the problem you care about. If 58 checks in an hour take 200 ms and two take 9 seconds, the average is about 490 ms. That looks like “a bit slow”, when the truth is “fine, except when it isn’t”. Look at the median for the typical experience and the slowest checks for what your unluckiest users see. Compare across locations too: if one location is consistently 300 ms slower, that’s distance or routing, not your server.
Remember what a synthetic check measures: the time for one request from a data centre. It doesn’t include images, scripts or rendering in a real browser. For that, use user experience monitoring , which reports Core Web Vitals from actual visitors.
What StatusEagle website monitoring doesn’t do (yet)
Worth knowing before you choose a tool:
A website monitoring checklist
Checks from 3 locations, verified alerts, SSL and domain expiry included.
10 monitors · no credit card
Related monitoring
Pair these monitoring checks to ensure complete stack coverage.
Frequently asked questions
Still deciding? Start monitoring free and verify your first service in ~2 minutes.
Website monitoring is the automated, repeated checking of a website's availability, response time and correctness from external locations, with an alert when something fails. It usually includes uptime checks, performance tracking, content checks and certificate/domain expiry tracking.
Your first monitor takes about two minutes.
Free plan: 10 monitors, 3 locations, 1 status page. No credit card.