An alert said the website was down, and it was not, or you cannot tell. Work through the steps below in order. This page covers what you can do inside UptimeWire. For why false alarms happen in general, see Why Uptime Monitors Send False Alerts.

1. Open the incident and read the reason

Open the incident from the alert, or from the list of incidents. The "Why it failed" section gives the reason for the failed checks and advice for it. Look at the times too: one failure at an odd moment points to a passing blip, while a failure at the same hour every day points to something that runs on your side at that hour.

2. Match the reason to a fix

Reason shown What it usually means What to do
The answer was a 403 or 401, or a challenge page A firewall or bot protection is refusing automated requests Allow the monitor. Its requests identify as UptimeWireBot/1.0. See Monitor reports 403 but the site works
The server did not answer in time The page took longer than 15 seconds Monitor a lighter address, such as a simple page or a health page
Connection refused, or a connection error Nothing was listening, or a firewall closed the port Check the server and the firewall
The name did not resolve DNS did not return an address Check the domain's DNS records
A certificate error The certificate is expired, wrong, or incomplete Check the certificate chain
More than 5 redirects A redirect loop or a long chain Fix the redirects
An answer outside the working range, such as 404 or 503 The address answers, but not with success Check that the address is correct, or change which answers count as working
The expected text is missing, or unwanted text was found A page-text rule failed Review the rule

3. Use the settings you have

Open the website's settings.

  • Address. Use a public address that answers quickly. A page behind a login cannot be checked.
  • Answers that count as working. The default is 200 to 399. If your site answers 401 on purpose for a monitor, add it to the list, for example 200-299, 401. Once you type a list, only those answers count.
  • Page text. UptimeWire reads the raw HTML of the page. Text added by JavaScript in the browser is not in it. Use the button that tests the text before you save the rule.
  • Interval. A shorter interval finds real outages sooner, and it does not remove false alarms.
  • Planned work. If you caused the failure on purpose, such as a deployment, note planned work in advance. See How to Read an Incident.
  • Reminder. On the Notifications page you can choose when you are reminded about a long outage, or switch the reminder off.

What you cannot change

UptimeWire does not alert on a single failure. It repeats a failed check and opens an incident only after three failures in a row, about 20 seconds apart. When more than one location is available, a majority of the locations that answered must agree, and a second server can be asked for its view. You cannot change the number of failures or the delay between them. This removes most false alarms and cannot remove all of them.

What not to do

  • Do not lengthen the interval just to quiet alerts. It only delays the detection of real outages.
  • Do not pause the website to stop the noise. A paused website is not checked at all.
  • Do not ignore a pattern. A website that fails at the same time every night has a cause.

Still not sure

Send the details to support. Contact Support says what to include.