Most website owners do not ask "is my site up?" until a customer tells them it is not. Availability monitoring moves that moment earlier. This page follows one outage from the first failed check to the recovery, and shows what you can and cannot learn along the way.

It assumes the monitoring is already set up. If it is not, start with the guide How to Monitor Website Availability.

What an availability check tells you

An availability check requests one address on a schedule and looks at the answer. It tells you whether the address answered, how the server responded, and how long it took. It does not tell you what is wrong.

A monitored address is one exact URL. If you monitor https://shop.example.com/, that is the only page being checked. The checkout, the sign-in page, and the API at another address are not covered unless you add them as websites of their own.

An illustrative outage

The following is an invented example, not a customer story. A small shop monitors https://shop.example.com/ every 3 minutes, and the alerts go to a shared mailbox the owner reads.

  1. The first failed check. The server starts answering with an error. The check is recorded as a failure.
  2. Confirmation. UptimeWire does not alert on one failure. It repeats the check a short time later. Only if the failure continues does an incident open.
  3. The alert. The owner gets a message that the website is down, with the time the incident opened.
  4. The investigation. The owner opens the website, then the hosting panel, and finds that the database server restarted.
  5. Recovery. Once the address answers again, the recovery is confirmed and a second message arrives.
  6. The review. A few days later the owner opens the history, sees the incident and its length, and compares it with earlier ones.

None of these steps is instant. The alert arrives after the check interval, the repeated checks, and the delivery of the message. No monitoring tool can promise an exact detection time.

Reading the alert

An outage alert says that a monitored address stopped answering correctly and that the failure was confirmed. It does not say why. What it does give you is a starting point:

  • Which website. The alert names the monitored address.
  • When it began. The incident has a start time, which helps you match it with a deploy, a backup, or a provider notice.
  • What the check saw. An error status, a timeout, or no answer at all point to different places to look. The HTTP status codes article explains the common ones.

Alerts by email and Telegram are available on every plan. Webhook, Discord, Slack, and Teams carry outage and recovery messages as well, depending on the plan. See Pricing for which plan includes which channel.

What to check first

UptimeWire does not diagnose the cause, so the first minutes are yours. A short order that works for most small websites:

  1. Open the address yourself, in a private browser window. If it loads, the problem may be brief or limited to some visitors.
  2. Look at the status your server returns. A 5xx error points to the server or application. A timeout points to the network or an overloaded server.
  3. Check the hosting provider. Look for a status notice or a restart.
  4. Check what changed. A deploy, a plugin update, or a configuration change shortly before the incident is a common cause.
  5. Confirm the recovery once you act, and wait for the recovery message.

Note

UptimeWire tells you that the problem exists. It does not find the cause and it does not fix anything.

Using the history after recovery

When the incident is over, the history turns one bad hour into information:

  • Start and length. How long the website was unavailable, to compare with what you expected.
  • Patterns. Failures at the same time of day suggest something scheduled, such as a backup or a heavy job.
  • Response time around the incident. A website that was slow before it failed points to a resource problem rather than a sudden break.

How many days of history you can see depends on your plan. The Uptime and Downtime glossary entries explain how these figures are counted, and the Uptime Calculator shows how much downtime a given percentage allows.

What availability monitoring does not cover

Be clear about the limits, so a quiet inbox does not give false comfort.

  • A healthy answer is not a working website. A page can answer normally while checkout, sign-in, or a back-end service is broken. You can add a rule that looks for a given text on the page, which narrows the gap but does not close it.
  • One address is not the whole website. Other pages, subdomains, and APIs need their own entries.
  • Detection is not instant. The interval sets how often the address is requested. Confirmation and delivery add time.
  • There is no browser-based testing. UptimeWire does not run user journeys such as adding an item to a cart.
  • There is no root-cause analysis. The alert says what failed and when, not why.

When this fits

This approach suits a website that people depend on, where the team needs to know about a failure quickly and see what happened later: a shop, a booking page, a company site, a documentation site. It does not replace testing the features of an application.