Manage GPL

← Uptime monitoring

Uptime monitoring

Understanding uptime incidents and down/up emails

What each type of uptime email means, how to interpret incident status codes, and when you should (and shouldn't) panic.

Updated

When a site goes down, you'll get an email. When it comes back up, you'll get another. This article explains exactly what each email means and how to act on it.

The "Site is down" email

Sent immediately when a check fails. Includes:

  • Site name + URL
  • Timestamp of the failed check
  • Error message (HTTP code, timeout, DNS error, SSL error, etc.)
  • Link to the incident in Manage GPL

Common causes, in rough order of frequency:

  1. Host is rebooting or restarting PHP. Often auto-resolves within a minute.
  2. Traffic spike. Too many requests; server refused or timed out.
  3. SSL certificate expired. Shows as an SSL error. Fix by renewing the cert.
  4. DNS is misconfigured or expired. Shows as a DNS error.
  5. Firewall change just deployed. Check recent deploy history.
  6. Actually down. Host outage; check your host's status page.

The "Still down" email

If the incident is still open after ~30 minutes (by default), you get a reminder. Throttled according to your settings — default cap is 2 down-emails per hour per incident.

The "Site is back up" email

Sent once, when the first check after an open incident returns healthy. Includes:

  • Site name + URL
  • How long the incident lasted
  • Link to the incident record for details

Never throttled — you always get the up-email even if down-emails were capped.

Interpreting HTTP status codes

  • 5xx (500, 502, 503, 504): the server received the request but failed to respond correctly. Usually PHP or application-level.
  • 404: the site URL doesn't exist. Usually means the URL in Manage GPL is stale (someone renamed a domain).
  • 403: the server actively refused the request — a security plugin or host-level firewall rule.
  • DNS error: domain doesn't resolve. Check DNS records.
  • Timeout: the server didn't respond within 10 seconds. Server is overloaded or unreachable.

What Manage GPL won't detect

Uptime checks hit the site's root URL with an HTTP HEAD. We detect:

  • The site being completely unreachable.
  • Full-site PHP errors that surface as 500s.
  • SSL and DNS issues.

We don't detect:

  • Individual page errors (if the homepage works but checkout is broken, we won't know).
  • Slow but not-quite-timing-out pages.
  • JavaScript errors.

For deeper checks, you'd need a dedicated synthetic monitoring tool. Manage GPL's uptime is designed for "is the site reachable at all" — a first line of defence.

More in Uptime monitoring

Is something wrong with this article?

Tell us so we can fix it — outdated info, broken steps, wrong numbers, anything.

Report an issue

Article: Understanding uptime incidents and down/up emails

Still stuck?

If this article didn't solve it, open a ticket and we'll help.

Open a support ticket