How to Monitor Website Availability

To monitor website availability you need four decisions: which address to watch, how often, who gets told, and what counts as a failure. This guide takes them in order and shows how each one looks in UptimeWire. The reasoning applies to any monitoring tool, so you can use it to judge others as well.

If you want the background first, read the Complete Guide to Website Uptime Monitoring.

What availability monitoring detects

An availability monitor requests your address on a schedule and checks the response. It catches:

• A server that is down or not answering.
• A server that answers with an error, such as 500 or 503.
• A domain that no longer resolves.
• A redirect that loops or never settles.
• A connection that times out.

It does not catch problems that leave the response looking healthy, such as a broken checkout behind a normal page. Later in this guide you will see how to narrow that gap.

Choose the exact address to monitor

Pick the address a visitor would actually use, written out in full, including https://.

• Use the final address. If http://example.com redirects to https://www.example.com, monitor the second. The monitor follows redirects, but the final address is the one that matters, and it saves a step.
• One address watches one page. Monitoring https://example.com/ does not cover https://shop.example.com/ or https://example.com/api/. In UptimeWire one website is one exact address. Add each important one separately.
• Prefer a page that proves something. A static home page can load while the application behind it is broken. If you have a lightweight health page that touches the database, monitor that as well.
• Avoid addresses that need sign-in. A monitor cannot log in. A page that answers 401 or 403 to strangers is reported as a failure.

Understand HTTP status codes

For each check, the monitor reads the status code. The HTTP status codes article explains them in full. The short version for monitoring:

UptimeWire follows redirects, up to a limit of five, then judges the final answer. A status from 200 to 399 means available. Anything else is a failure.

Choose a check interval

The interval is the gap between checks. A site that fails can only be caught by a check that runs while it is down, so a shorter interval finds problems sooner.

UptimeWire offers these intervals: 1 minute, 3 minutes, 5 minutes, 15 minutes, 30 minutes, 1 hour, 6 hours, 12 hours, and 1 day. Your plan sets the shortest you can choose:

Intervals shorter than your plan allows appear in the form as locked, with the plan that unlocks them.

How to choose:

• Shop, booking, or paid service: the shortest interval your plan allows.
• Company site or documentation: 5 minutes is plenty.
• A site you only need to know is not gone for days: 30 minutes to an hour.

The interval is not the same as detection time. A failed check is repeated before it becomes an incident, as explained below.

Set up monitoring in UptimeWire

These steps match the current product. Screens can change, so treat the names as a guide.

1. Create an account at app.uptimewire.com.
2. Confirm your email address. You cannot add a website until the address is confirmed. Monitoring starts after that.
3. Start the first website. A short setup asks three things, one screen at a time, and shows a summary of what will be done.
   1. Website. The address to watch, and a name.
   2. Checks. The interval, how many days before expiry to warn about the certificate and the domain, and an optional page-text rule.
   3. Alerts. The email address that receives alerts for this website.
4. Press "Start monitoring". You can also use "Start now", which uses the settings already on the page, or skip the setup and add a website later. Settings can be changed afterwards.
5. Watch the first check. A screen follows and shows the first result when it arrives: running, up, could not open, or taking longer than expected.

Each website you add also gets certificate, domain expiration, and DNS checks. They run on their own schedules, apart from the interval you chose.

Configure the alert email

The alert email belongs to the website. It is where outage and recovery messages go, and also where warnings about the certificate, domain, and DNS go.

Use an address that someone reads. A shared inbox that nobody opens gives you monitoring without anyone reacting to it. For a team, use a group address so that the alert does not depend on one person.

Add more notification channels

Email is the default. Other channels are optional and are set up once, for the whole account, in the notification settings of your profile. They then apply to every website.

Which channels you can use depends on your plan. See Pricing for the current list.

Not every channel carries every message:

How incident confirmation works

When a check fails, UptimeWire does not alert at once. It repeats the check a short time later, and opens an incident only after the failures continue. Where a second check point is available, it can also be asked whether it sees the same failure.

This is deliberate. Short blips, a packet lost on the way, or a brief restart would otherwise raise false alarms, and false alarms teach people to ignore the real ones. When an incident opens, you are notified. When the site answers again, the recovery is confirmed and you are told that too.

The cost is time. The alert arrives after the interval, the repeated checks, and the delivery of the message. No monitor can promise an exact detection time, and a guide that does is overselling.

Add a page-text rule when 200 is not enough

If your site can answer 200 with the wrong content, add a page-text rule to the check. In the "Checks" step you can choose to treat it as a failure when a given text is missing from the page, or when it appears.

For example, a text that is always on your page, such as a phrase in the footer, tells you the real page loaded. A text such as "Error establishing a database connection" tells you the error page is showing.

Things to know:

• The text must match exactly as it appears in the page source, capital letters included.
• Only the first megabyte of the final page is read.
• A missing text is treated like any other failure: repeated and confirmed before you are alerted.
• Use the "Test this text" button before saving, to make sure the rule behaves as you expect.

Review the first results

After the first check, look at three things:

1. The status. Is the website up? If it says it could not open the address, compare the address with what you type in a browser.
2. The response time. Note the number. It is your baseline, and later changes make sense against it. See response time for what the figure includes.
3. The certificate, domain, and DNS state. These checks run on their own schedules, so they may show a result a little after the first check.

If the first check fails and the site works in your browser, the usual causes are a typo in the address, a page that requires sign-in, a firewall that blocks automated requests, or a redirect that loops.

Interpret the monitoring history

Over days, the history shows patterns that a single check cannot:

• Isolated failures at the same time of day point to something scheduled: a backup, a deploy, a heavy job.
• A response time that slowly rises points to a growing database, a leaking process, or a plan that is too small.
• Long incidents show where your recovery is slow, not only your detection.
• No incidents for weeks is a good result. It is also a reason to check once that alerts still arrive.

Uptime is the share of the period the site was available. Use it as a trend for yourself, not as a promise to customers.

Test your notifications

Do not wait for a real outage to learn that an alert goes to spam or to the wrong person.

1. Add a test website with an address that does not exist, or use a page-text rule that you know will fail.
2. Wait for the incident to open.
3. Check that the email arrives, and that the other channels you enabled deliver as well.
4. Check the recovery message after you fix the test.
5. Delete the test website.

Look in spam folders and filters. If a team receives the alert, check that each person actually does.

Common monitoring mistakes

• Monitoring only the home page. The checkout, login, and API can break while the home page is fine.
• Choosing the wrong address. Monitoring an address that redirects, needs sign-in, or is cached by a CDN can hide real problems.
• An unread alert inbox. Monitoring that nobody reads is not monitoring.
• Trusting 200 too much. Add a text rule, or monitor a deeper address.
• Assuming one address covers a domain. It does not cover subdomains or other paths.
• Setting up once and never testing. Check the alert path from time to time.
• Relying on a chat channel alone. Certificate warnings come by email and Telegram only.

Setup checklist

• The exact address, with https://, loads without signing in.
• The interval matches the cost of an outage and is allowed by your plan.
• The alert email is read by a person.
• Extra channels are connected in the profile, if you want them.
• A page-text rule is set where a plain 200 is not enough.
• A test alert and its recovery arrived.
• Every important address is added as its own website.
• Certificate, domain, and DNS warnings are set to the lead time you need.

Next, learn how to avoid one of the most preventable outages: How to Prevent SSL Certificate Expiration.