How to automate uptime monitoring and tell people what is happening

Uptime monitoring is usually treated as a detection problem, and detection is the easy half. A check runs, it fails, somebody is paged. What happens over the following hour — whether customers find out from you or from each other, whether support knows before the tickets arrive, whether anything is recorded — is what people actually judge you on.

None of that happens well under pressure unless it was built in advance, because the moment an outage starts is the moment nobody has time to write a status update from scratch.

What we'll cover

• What "up" means to a customer
• Detection, briefly
• The status page that updates itself
• Building it with CodeWords
• Telling support before the customers do
• Writing the update
• The record, and what happens after
• Planned maintenance, which is the easy half done badly
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What "up" means to a customer

Reachable is not usable. A site that loads in eleven seconds is down as far as anybody trying to use it is concerned.

Partially working is the common case. Checkout broken while everything else works is an outage for the people trying to buy and invisible in an overall availability figure.

Regional failures look like full health from wherever your monitoring happens to run.

One customer segment can be down — a client version, an authentication method, a payment provider — which no aggregate number reflects.

So define availability per journey, not per site, and report against those. "The site is up" is a statement nobody can act on and nobody quite believes.

The uptime percentage is a poor summary. Three nines sounds reassuring and permits hours of downtime a year at the worst possible moments, so report incidents and durations rather than a figure.

Detection, briefly

Covered in depth elsewhere, so only the parts that affect communication.

Check from outside, from more than one location, since a single-location check cannot distinguish a regional problem from a total one.

Require consecutive failures from several locations before declaring anything, because a false status update is worse than a slightly delayed true one.

Distinguish degraded from down, since the two need different messages and conflating them either overstates or understates.

Know which journey failed, because "we are investigating an issue" is far less useful than "checkout is affected".

Detect recovery too, and with the same rigour — a premature all-clear is the most damaging update you can send.

The status page that updates itself

The artefact customers look for, and the one that is usually stale.

Create the incident automatically on confirmed detection, in an investigating state, with the affected component named.

Say what is affected, not what is broken. Customers care which of their journeys works, not which service failed.

Update on a cadence — every twenty or thirty minutes — even when there is nothing new, because silence reads as nobody working on it.

Automate the reminder to update, not the update text itself, since a person should write what is said and the automation should make sure somebody does.

Resolve automatically only on sustained recovery, with a margin, since flapping produces a resolve-and-reopen sequence that destroys confidence.

Host it independently. A status page on the infrastructure that is down is the oldest mistake in this area and it is still common.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so detection can reach the status page, support, and the incident record in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what confirms an incident, what should be created, and who should be told.
3. Authorize the connections — the monitoring source, the status page, the support tool, and the team's channel.
4. Describe the exceptions: a flapping check, a known maintenance window, a recovery that does not hold.
5. Trigger a test incident deliberately and watch the whole sequence run.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Telling support before the customers do

The most appreciated automation in this whole area and one of the simplest.

Support learns about outages from tickets, which means the first customer gets a confused answer.

Post to their channel on detection, with what is affected and what to say, before the tickets arrive.

Give them the words. A prepared holding response saves every agent writing their own and keeps the message consistent.

Update them when the status changes, including on resolution, so nobody is still apologising for something that was fixed an hour ago.

Tell account managers about affected named accounts, since those customers expect to hear from a person rather than read a status page.

Report afterwards how many tickets it generated, which is the number that justifies the whole arrangement.

Writing the update

Say what is affected and what is not. Customers are trying to work out whether their thing works.

Say what you know, not what you suspect. Speculation that turns out wrong is remembered.

Give a time for the next update, not an estimate for the fix — the first you can keep and the second you usually cannot.

Avoid the passive. "We are investigating" is fine; "an issue has been identified" reads as evasion.

No jargon. Customers do not know what your services are called.

Do not apologise repeatedly in every update. Once, sincerely, and then information — repeated apology reads as filler and delays the part people want.

The record, and what happens after

Start the timeline automatically at detection, and append status changes as they happen, because reconstructing afterwards is unreliable and nobody wants to do it.

Capture what was happening around the start — deployments, configuration changes, third-party status — at the time, since that context is hardest to recover later.

Record the customer impact: duration, affected journeys, tickets raised, and named accounts, which is what any review will ask for first.

Generate the review document from the timeline, so the meeting starts with facts rather than with somebody assembling them.

Track the actions from the review in the place work actually happens, not in the document, or they are not done.

Report incidents monthly with durations and causes, since the pattern across incidents is more informative than any single one.

Planned maintenance, which is the easy half done badly

Everything above concerns unplanned outages. The planned ones are entirely predictable and are still communicated poorly.

Announce in advance, with enough notice for customers to plan around it — which for a business tool means days rather than hours.

Say what will be unavailable, not that "maintenance will occur", since customers are working out whether their Tuesday is affected.

Choose the window by their timezone, not yours, which for an international customer base means somebody's working day is affected and choosing deliberately is better than defaulting.

Suppress alerting for the window, automatically, so the team is not paged for something they scheduled.

Post the maintenance notice on the status page at the same time, from the same automation, rather than as a separate thing somebody remembers.

Confirm when it is done, which is the step most often skipped and the one that tells people they can stop waiting.

Making it survive

Run the monitoring and the communication outside your own infrastructure, so an outage does not take them with it.

Make incident creation idempotent, so a flapping check produces one incident rather than nine.

Suppress during planned maintenance, with a window, and post the maintenance notice automatically instead.

Handle the automation failing by alerting through a different route, because the one time it matters is the one time everything else is broken.

Report the outcome. Incidents opened, updates posted, notifications sent, and anything that failed to reach its destination.

Limits worth knowing about

External checks see what they test, so a journey nobody scripted can be broken while everything reports healthy.

Uptime percentages are a weak summary that hide when and for whom the downtime happened.

Third-party dependencies are your outage from a customer's point of view, whoever caused it, and your status page has to say something regardless.

Automated status updates can be wrong, which is why detection thresholds matter more here than for internal alerting.

Communication is a judgement, and the automation should prompt and prepare rather than decide what is said.

What to build first

The support notification: when an incident is confirmed, post to the support channel with what is affected and a prepared holding response, before the tickets arrive. It is a small automation, it removes the worst version of an outage for customers, and it costs nothing when nothing is wrong.

Two habits make the difference. Include the suggested wording rather than only the alert, since consistency across agents during an incident is what prevents contradictory answers. And notify on recovery with the same prominence, because support apologising for something fixed an hour ago is a small, avoidable embarrassment that happens constantly.

Frequently asked questions

What does "up" actually mean?

Per journey rather than per site. Reachable is not usable, partial failures are the common case, and a regional outage looks like full health from elsewhere. An overall availability figure hides all three.

Should status page updates be automated?

Create the incident automatically on confirmed detection, and automate the reminder to post updates — but have a person write what is said. Resolve only on sustained recovery, since a premature all-clear is the most damaging update there is.

How often should we update during an incident?

Every twenty or thirty minutes, even with nothing new, and always give a time for the next update rather than an estimate for the fix. Silence reads as nobody working on it.

Why tell support first?

Because otherwise they learn about outages from tickets, and the first customer gets a confused answer. Give them what is affected and a prepared holding response before the tickets arrive.

Where should the status page be hosted?

Anywhere other than the infrastructure it reports on. A status page that is down during an outage is the oldest mistake in this area and it still happens regularly.

What should the incident record capture?

A timeline started at detection, what was happening around the start — deployments, configuration changes, third-party status — and the customer impact. That context is hardest to recover afterwards and is what any review asks for first.

Is an uptime percentage worth reporting?

Not on its own. It hides when the downtime happened and who it affected, and three nines permits hours a year at the worst possible moments. Report incidents, durations, and affected journeys.

How should planned maintenance be handled?

Announced days ahead with what specifically will be unavailable, scheduled by the customer's timezone rather than yours, with alerting suppressed for the window automatically — and confirmed when it finishes.

What gets forgotten about maintenance windows?

The completion notice. People plan around the window and then have no way to know it is over, so they wait longer than necessary or check repeatedly. It is one line and it is almost always missing.

Related reading

• Automating API health checks
• Automating synthetic monitoring
• Automating Slack alerts from monitoring tools