How do I find out my site is down before my customers tell me?
Run an uptime check from outside your own network that requests a health URL every minute or few minutes and alerts you when it fails. Check the status code, the response time and a keyword or health endpoint that actually touches your database. Require a failure from more than one region before alerting, and send alerts to a channel someone watches.
Why it happens
Customers are the default monitoring system for any site that has none. They only report an outage after they have been hit by it, and most never report it at all; they leave. Your own tooling often stays quiet during an outage because it shares the failure: a server that is down cannot send you an email about itself, a process that has run out of memory cannot log, and a misconfigured load balancer can drop every request before it reaches the application and its error tracker.
That is why the check has to run from somewhere else. An uptime monitor is a small service on a different network that requests your URL on a fixed schedule and compares the answer to what you expect. It sees the site the way a visitor does, including problems in DNS, TLS certificates, the CDN, the load balancer and the network path, none of which your application can see from the inside.
A check is only as good as what it asserts. A homepage that returns 200 from a cache while the database is unreachable looks healthy to a monitor that only looks at the status code. And a check that fires on one slow response from one location will wake you for problems that are not yours. Good uptime monitoring is mostly choosing what to assert and how many failures to require before you are told.
How to find out your site is down before your customers do (works with any uptime monitor)
Add a health endpoint that exercises what you depend on
Create a URL such as /healthz that returns a small response and, on every call, runs the cheapest real query against your database and, if you rely on one, your cache. Return 200 only when those succeed and 503 when they do not. A 503 is the documented answer for a server that is not ready to handle the request, for example during maintenance or overload (MDN, read 2026-11-13). Keep the endpoint fast, and do not put secrets or version details in the response.
app.get('/healthz', async (req, res) => { try { await db.query('select 1'); res.status(200).json({ ok: true }); } catch (err) { res.status(503).json({ ok: false }); } });Monitor from outside your own network and assert more than the status code
Point an external monitor at the health URL and at your public homepage. Assert the status code, a response time ceiling, and a keyword that must be in the body: your product name on the homepage, or the word ok in the health response. The keyword catches an error page or a maintenance page served with a 200 by a proxy. Use HTTPS, so an expired certificate is caught as a failure too.
Pick an interval and a confirmation rule together
A one-minute interval finds an outage faster but produces more false alarms if each failure alerts. A five-minute interval is quieter but can leave you in the dark for several minutes. Whatever the interval, do not alert on a single failed request: require two or three consecutive failures, or a failure from more than one probe region, before the alert goes out. A network blip between one probe and your site should not wake anyone.
Set a timeout that matches what a user would tolerate
Make the timeout shorter than the point where a visitor would give up, such as 10 seconds, and treat a timeout as a failure. Record latency over time as well: a health endpoint that takes 200 ms on Monday and 4 seconds on Friday is telling you something before it fails. Look at a high percentile, not only the average, because averages hide the slow tail that users feel.
Send alerts to a place that is seen, and tell customers through a status page
Route the down alert to a channel with a named owner, not to a shared inbox, and send recovery notices to the same place so people know the incident is over. Send the alert through a second path, such as a webhook to a chat room and an email, so one broken notification path does not silence you. A hosted status page, separate from your own infrastructure, lets customers check for themselves and cuts the volume of support messages during an outage.
Test it by breaking something on purpose
Make the health endpoint return 503 for a few minutes on a staging copy, or stop the database there, and confirm the alert arrives in the right place, with the right wording, within the interval you chose. Do this again after you change alert destinations. An unexercised alert path is the most common reason an outage is discovered by customers first.
| Assertion | Catches | Does not catch |
|---|---|---|
| Status code is 200 | Server down, 5xx errors, routing and DNS failures, an expired TLS certificate | A broken page served with a 200 |
| Response time under a limit | Overload, slow database, a degraded dependency | A fast but wrong response |
| Keyword present in the body | Error pages and maintenance pages served with a 200 | A page that renders but a button that is broken |
| Health endpoint touches the database | Lost database connection, exhausted connection pool | A bug in a feature that does not use that query |
| Failure from several regions | Reduces alerts from one probe's network problems | Slower detection than alerting on one failure |
Reasoning about status codes follows the HTTP semantics in the MDN 503 documentation (read 2026-11-13); the remaining rows are the author's criteria, not vendor claims.
When to use Bugsly
Bugsly has an uptime monitor that makes HTTP requests to a URL with a method you choose, an expected status code (default 200), an interval (default 300 seconds), a timeout (default 10 seconds) and optional regions. It records uptime percentage, average latency and p95 latency, and the uptime down alert condition can send to email, Slack, Telegram or a webhook. Uptime monitoring needs a plan that includes monitors; see /pricing.
The reason to run it next to error tracking is the gap the table above shows: an uptime check says whether the site answered, and the error tracker says what broke when it did answer. An assistant connected over MCP can read both: list_uptime_monitors shows which URLs are checked, and get_uptime_status returns uptime, average latency and p95 for a window you choose in hours.
Bugsly's uptime check is a plain HTTP request. It is not a browser test and it does not run a user journey.
When Bugsly is not the right answer
If you need synthetic tests that drive a real browser through a login, a cart and a payment, an HTTP check will not do it: use a dedicated synthetic-monitoring tool. Bugsly also does not host a public status page, so use a status page service if you want to tell customers about an incident.
If you need to be paged by phone with escalation when nobody responds, send the uptime alert to a tool built for that through a webhook; Bugsly itself only delivers to email, Slack, Telegram and webhooks.
Ask your AI assistant to do it
With the Bugsly MCP server connected (https://bugsly.dev/api/mcp; setup for ChatGPT, Claude, Cursor and Gemini CLI is on /mcp), paste this. The assistant reads first and reports back; you decide what happens next.
Assign to Bugsly: use list_uptime_monitors for my project, then get_uptime_status with hours 168 on each monitor and tell me which sites had downtime, the uptime percentage, the average latency and the p95 latency. Do not change any monitor; show me what you found so I can approve the next step.
Frequently asked questions
How often should an uptime check run?
Every one to five minutes suits most sites. Shorter finds outages sooner but needs a confirmation rule, such as two failures in a row or failures from two regions, so a single bad response does not alert you.
Why does my site show as up when users report errors?
Because the check only asked whether the URL answered. A page that returns 200 with a broken checkout is invisible to it. Pair the uptime check with error tracking and a health endpoint that exercises the database.
Should the uptime monitor run on my own servers?
No. A monitor that shares the host or network of the site goes down with it and cannot alert you. Run it from a separate provider and, ideally, from more than one region.
Do I need a status page as well?
It is not required to detect an outage, but it reduces support load during one because customers can see that you know. Host it outside your own infrastructure.
Sources
- MDN: 503 Service Unavailable (read 2026-11-13)
Related
- Uptime monitoring guide
- How do I get alerted when a cron job silently stops running?
- Why does my team ignore error alerts?
- All problems and solutions
Sentry is a trademark of its owner; Bugsly is not affiliated with or endorsed by Sentry. “Sentry-compatible” only means Bugsly accepts events sent by Sentry's open SDKs.