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
On this page
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:
- Host is rebooting or restarting PHP. Often auto-resolves within a minute.
- Traffic spike. Too many requests; server refused or timed out.
- SSL certificate expired. Shows as an SSL error. Fix by renewing the cert.
- DNS is misconfigured or expired. Shows as a DNS error.
- Firewall change just deployed. Check recent deploy history.
- 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
Report sent — thanks!