Guide Updated February 2026 Read time: 7–9 minutes

What Counts as Website Downtime (And What Doesn’t)

“Down” can mean different things: a server returning 500 errors, DNS failures, timeouts, or a partial outage that only affects some users. This guide explains what counts as downtime, what doesn’t, and how to decide in real-world situations.

Short definition

Your site is “down” when users cannot reliably complete the primary action they came to do — even if the homepage still loads.

What counts as downtime

500 errors (server error)

5xx responses indicate the server is unable to fulfill requests. If these appear for normal requests, that’s downtime.

Timeouts

If requests exceed your timeout threshold or the connection closes before a response arrives, users effectively experience downtime.

DNS failures

If your domain doesn’t resolve (NXDOMAIN, SERVFAIL, or timeouts), users can’t reach your site at all.

Partial outages

The homepage might load, but checkout, login, or API calls fail. That’s still downtime for the affected users.

How the common failure types show up

500 errors

500 Internal Server Error means the server encountered an unexpected condition that prevents it from fulfilling the request. A spike of 500s indicates a backend failure or misconfiguration.

Timeouts (HTTP, TCP, or TLS)

If requests hang or connections close before the response arrives, users see the site as down. A 408 can also indicate an idle connection timeout.

DNS errors (NXDOMAIN, SERVFAIL)

NXDOMAIN means the name doesn’t exist; SERVFAIL means the resolver failed to complete the query. Both prevent users from reaching your site.

Partial outages

A CDN or API dependency can fail while the main site looks healthy. These require targeted checks, not just a homepage ping.

What doesn’t count as downtime

Slow but functional

High latency is still a serious issue, but if users can complete critical actions, it may be categorized as “degraded” rather than down.

Isolated local issues

A single user’s ISP issue or device problem is not a site outage. This is why multi‑location checks matter.

Planned maintenance (if communicated)

If users are informed and service is expected to be unavailable, this may be tracked separately from unplanned downtime.

Non-critical pages failing

If a blog post fails but checkout is fine, it’s an issue — but not a full outage. Track it as partial or degraded performance.

How to decide if it’s downtime

  1. Define critical user actions (e.g., login, checkout, booking).
  2. Monitor those endpoints directly, not just the homepage.
  3. Set a timeout threshold users would consider “failed.”
  4. Use multi‑check confirmation from different locations.
  5. Classify incidents as full, partial, or degraded.

Want reliable downtime detection?

Start a 30-day free trial and get alerted the moment your site goes down.

FAQ

Is a 500 error always downtime?

Yes. 5xx responses indicate the server failed to fulfill the request, which is downtime for users hitting that endpoint.

What about 404 errors?

A 404 is typically not downtime unless it affects a critical page or flow (like checkout, login, or payment).

Is slow performance considered downtime?

Slow responses are often classified as degraded performance, not full downtime — but severe slowness can be as harmful as an outage.

How do I detect partial outages?

Monitor key transactions and APIs, not just the homepage. Partial failures often affect one critical path.

Do DNS issues count as downtime?

Yes. If DNS fails to resolve, users can’t reach your site at all.

Sources

RFC 7231: definition of 500 Internal Server Error and 5xx class.

MDN HTTP 408 Request Timeout: server closes idle or slow connections.

DNS failure modes: SERVFAIL vs timeouts and their causes.

NXDOMAIN definition: name does not exist in DNS.

DNS TTL behavior and propagation timing.