An incident is UptimeWire's record that a website was down: when it began, why, and when it ended. This page explains how one opens, what the incident page shows, and how it closes.
What "down" means
For the availability check, UptimeWire sends an HTTP request to your address, follows redirects, and waits up to 15 seconds for an answer. A final answer from 200 to 399 counts as working. Anything else is a failed check. That includes 401 and 403, a timeout, a refused connection, a name that does not resolve, a certificate error, too many redirects, and a failed page-text rule.
You can change which answers count as working in the website settings. If you type a list such as 200-299, 401, only those count.
How many failures open an incident
One failed check does not make an incident. When a check fails, UptimeWire checks again after about 20 seconds. The incident opens after three failed checks in a row.
This is why the website can show "Checking" first. The status means that a check failed and UptimeWire is confirming before it tells you. No alert has been sent at that point.
If your plan includes more than one check location, a check counts as failed only when more than half of the locations that answered report a failure. A tie is not an outage.
The second opinion
When only one location took part in the check, UptimeWire can ask a second server on a different network for its view before it opens the incident. This is the "second opinion". If the second server sees the website working, the incident does not open, which removes failures that come from the path between one monitor and your site. If the second server cannot be reached, the incident opens without it.
Why the alert comes after about a minute
The alert waits for the confirmation, so it arrives later than the first failure. That is the price of fewer false alarms. The delay comes on top of your check interval, and the shorter the interval, the sooner you hear. UptimeWire does not promise a detection time. Delivery also depends on your email provider or the receiving service.
The incident page
Open an incident from the list of incidents, or from the link in an alert. The page shows:
- Duration, Started, and Ended. Started is the time of the first failed check of the three. While the incident is open, Ended says "Not yet".
- Failed checks. How many checks failed.
- Why it failed. The reason, with advice. Common reasons are a timeout, a refused connection, a name that does not resolve, a certificate error, an answer outside the working range, and too many redirects. Read this first: it usually names the cause.
- Timeline. The first failed check, the moment it was confirmed, when the website came back, and the alerts that were sent.
- Locations. How many checks failed at each location.
- Site now. What the website looks like at this moment.
- Planned work badge, if the incident began during a maintenance window.
Each alert on the timeline has a status, such as sent, not sent, on its way, not delivered, or held until the work ends.
UptimeWire keeps the details of the failed checks for 90 days. After that, the incident summary remains.
How an incident closes
An incident closes after two successful checks in a row. UptimeWire then sends a recovery alert through your channels. The recorded end of the incident is the time of the first of those two successful checks.
If a website is paused while an incident is open, the page says that monitoring is paused and that the end time is not known. A paused website is not checked at all, so pause it deliberately.
Planned work
For work you can predict, such as a deployment or a restart, note planned work for the website so that it does not wake anyone.
- Open the website and go to its "Planned work" tab.
- Press "Note planned work", then set the start, the end, and a note.
While the work is running:
- Checks keep running, and the failures stay in the history.
- An outage that begins inside the window is not counted as downtime in your SLA report or on status pages.
- No alert about that outage goes out unless the website is still down when the work ends. If it is still down, the alerts are sent then. If it recovered inside the window, they are dropped.
- Warnings about the SSL certificate, the domain, and DNS are not held.
There are limits. A window must start at least 5 minutes from now and no more than 90 days ahead. One window can be at most 24 hours long. A website can have at most 48 hours of planned work per calendar month and at most 20 upcoming windows, and windows cannot overlap. An upcoming window can be cancelled. A window that has started cannot be moved, only ended sooner with "End now".
A window noted after an outage has already begun does not excuse that outage.
For more on the idea, see Maintenance window and Incident.
If the alert looks wrong
Read the reason on the incident page. If the website was fine for your visitors, see What to Do About a False Alarm.