Beamfar
Sign inStart free

Where the minutes go between an outage and the alert

By the Beamfar team. Published . Updated . 4 min read.

A client who finds the outage first has already lost visitors. Monitoring shortens the time between the first failed request and the moment someone who can act reads the alert. That time has parts you can set or measure, and none of them can be reduced to zero, so this guide does not promise that you will always hear first. It shows where the minutes go.

Where the time goes

From the moment a site stops answering to the moment a person reads about it, five things add up.

  1. Time until the next check. A monitor that checks every five minutes finds an outage, on average, two and a half minutes after it starts and five minutes after it starts at worst. A one-minute interval makes that one minute at worst. The check interval page and the guide on how often to check a website give the arithmetic.
  2. The retry. One failed request is often a network blip. Most tools repeat it a few seconds later before they call anything an incident.
  3. The confirmation step. A second request from another region, or several failed checks in a row, separates “the site is down” from “one path to the site is bad”. It costs time on purpose. The guide on two-region confirmation and false alarms compares the methods.
  4. Delivery. The alert has to leave the monitoring service, pass through the mail server, the chat service or the phone’s push service, and arrive. A provider that accepts a message has not delivered it. Delivery time is separate from detection time, and it is usually the part nobody measures.
  5. Attention. An alert in a mailbox nobody opens at night is not an alert. Who reads it, and how fast, is a matter of rules, not software.

Add the five and you have the honest answer to “how fast will we know”: up to one check interval, plus a retry and a confirmation step, plus delivery, plus attention. For a one-minute interval that is usually a few minutes, not seconds.

What to set up

Pick the interval from what a minute of downtime costs. A brochure site with no sales can live with five minutes. A shop in a campaign week cannot. A shorter interval costs more checks, not more attention, so the cost sits with the tool rather than with you.

Check what a visitor sees, not only that the server answers. A page that answers 200 and shows an error is up as far as a plain status check is concerned. Ask the check to find a piece of text that only appears when the page works, such as the add-to-cart button. What a 200 response hides lists the common cases.

Watch the things that fail on a date. Certificates and domain registrations expire on a known day. A warning two weeks ahead turns an outage into a task. See SSL certificate expiry on client sites and domain expiry and RDAP.

Send alerts where someone looks. E-mail alone is the weakest path. Add a chat channel the team reads, and for the clients that matter, a channel that rings a phone. The alert channels page lists what Beamfar sends to and from which plan.

Decide who acts, and what happens if nobody answers. Acknowledging an incident tells the team someone is on it. An escalation rule tells a second person when nobody has. Without both, the alert has no owner.

Test the path. Send a test alert to every channel after you set it up, and again after you change anything. A channel that has never carried a message is a guess.

What no tool can promise

  • Detection without delay. Detection has a floor set by the interval and the confirmation step.
  • An alert that always beats the client. A visitor can hit the error in the seconds before the first check fails. A client who refreshes the page at the wrong moment will see it first. What you can promise is a short, known delay and a record of what happened.
  • That the alert arrives. Mail and push services are outside the monitor’s control. If an alert is vital, send it by two paths.
  • Coverage of everything. An external check sees what an outside visitor reaches. It does not see behind a login, or a background job that stopped.

A short routine for an agency

  1. Put every client site under monitoring on the day it goes live, not after the first incident.
  2. Use the same alert channels and the same rules for every site, so nobody has to remember exceptions.
  3. For each site, write down who is told and who acts. Put it where the on-call person can find it.
  4. Read the incident record after every outage: when the first check failed, when the alert went out, when someone acknowledged. If the gaps are long, change the setting that caused them.
  5. Tell the client the time you detected the outage and what you did, in the same message. The incident communication guide has wording.

What Beamfar does here

Beamfar checks each site from more than one region and sends one alert for an outage, with what each region saw and, when something changed, what changed just before. The uptime monitoring page gives the check interval of each plan, and the incident page shows what each region saw and when; set that against the time the alert reached you to measure the parts above on your own sites. You can also check a site now without an account to see what an outside check reads. Beamfar does not promise that you will hear before your client does; it aims to make the delay short and to show you exactly how long it was.

Sources

Read on . Standards and vendor pages change; confirm the current text before you rely on it.

Terms used in this guide

  • Uptime monitoringUptime monitoring requests a website from outside at intervals and alerts when it fails to answer. What it measures, what it misses and how it is confirmed.
  • Check intervalThe check interval is the time between two uptime checks. How it sets the detection delay, the number of checks and how it interacts with confirmation.
  • IncidentAn incident is a period in which a monitored site is confirmed to be failing, from first confirmation to recovery. What an incident record should hold.
  • False positiveA false positive is an alert saying a site is down when it was reachable. Usual causes: the monitor’s network, DNS, firewalls and timeouts, and how to cut them.

Try it on your own sites.

Add your sites: checking starts as soon as you do.

Start freeSee every feature

No card for the Free plan.