How to automate uptime monitoring and tell people what is happening

To automate uptime monitoring well, automate more than detection: build the status page, the support alert, the customer update and the incident record before an outage happens. Detection is the easy half, because a check runs, fails and pages somebody. Customers judge you on the following hour: whether they hear from you or from each other, whether support knows before the tickets arrive, and whether anything is recorded.

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

What we'll cover

• What does "up" mean to a customer?
• What detection needs for good communication
• 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
• How should you handle planned maintenance?
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Key takeaways

• Define "up" per customer journey, not per site, because a reachable site can still be unusable.
• Create the status page incident automatically on confirmed detection, and have a person write what it says.
• Post to the support channel on detection, with the affected journey and a prepared holding response.
• Start the incident timeline at detection, so the review meeting begins with facts.
• Build the support notification first: it is small and it removes the worst version of an outage for customers.

What does "up" mean to a customer?

"Up" means a customer can complete the journey they came for. Define availability per journey, not per site, and report against those journeys. "The site is up" is a statement nobody can act on.

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

Partial failure 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 runs.

One customer segment can be down: a client version, an authentication method or a payment provider. No aggregate number reflects that.

The uptime percentage is a poor summary. Three nines (99.9%) still permits roughly nine hours of downtime a year, at the worst possible moments. Report incidents and durations instead of a figure.

What detection needs for good communication

Detection must confirm failures from several locations, tell degraded from down, and name the failed journey. Those three properties decide whether your first message is accurate.

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. A false status update is worse than a slightly delayed true one.

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

Know which journey failed. "Checkout is affected" helps customers more than "we are investigating an issue".

Detect recovery with the same rigour. A premature all-clear is the most damaging update you can send, because customers then lose trust in later notices.

The status page that updates itself

A status page that updates itself creates the incident automatically on confirmed detection, names the affected component and prompts a person to post updates. Customers look for this page first, and it is usually stale.

Create the incident 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 nothing is new. Silence reads as nobody working on the problem.

Automate the reminder to update, not the update text. A person should write what is said, and the automation makes sure somebody does.

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

Host the page 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 (CodeWords pricing page, 2026), 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 to create and who to tell.
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 (CodeWords pricing page, 2026). Details are on the pricing page.

Telling support before the customers do

Post to the support channel the moment an incident is confirmed, with what is affected and a prepared holding response. Support otherwise learns about outages from tickets, and the first customer gets a confused answer.

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

Update support when the status changes, including on resolution, so nobody apologises for something fixed an hour ago.

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

Report afterwards how many tickets the incident generated. That number justifies the whole arrangement.

Writing the update

A good incident update says what is affected, what is not, what you know and when the next update arrives. Customers are trying to work out whether their work is safe.

Say what is affected and what is not.

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. You can keep the first promise; you usually cannot keep the second.

Use the active voice. "We are investigating" is fine; "an issue has been identified" reads as evasion.

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

Apologise once, sincerely, then give information. Repeated apology reads as filler and delays the part people want.

The record, and what happens after

Start the incident timeline automatically at detection and append every status change. Reconstructing a timeline afterwards is unreliable, and nobody wants to do it.

Capture what was happening around the start: deployments, configuration changes and third-party status. This context is hardest to recover later.

Record the customer impact: duration, affected journeys, tickets raised and named accounts. Any review asks for these first.

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

Track the review actions in the place work happens, not in the document, or they do not get done.

Report incidents monthly with durations and causes. The pattern across incidents is more informative than any single incident.

How should you handle planned maintenance?

Announce planned maintenance days ahead, say what will be unavailable, choose the window by your customers' timezone and confirm when it ends. Planned downtime is entirely predictable, and companies still communicate it poorly.

Announce with enough notice for customers to plan around it. For a business tool, that means days rather than hours.

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

Choose the window by their timezone, not yours. For an international customer base, somebody's working day is affected, so choose deliberately.

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

Post the maintenance notice on the status page from the same automation, at the same time.

Confirm when it is done. Teams skip this step most often, and it tells people they can stop waiting.

Making it survive

An uptime automation survives when it runs outside your own infrastructure and creates one incident per outage.

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

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

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

Alert through a different route if the automation fails, 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 only what they test, and automation prepares communication rather than deciding it.

External checks see what they test. A journey nobody scripted can break while everything reports healthy.

Uptime percentages hide when and for whom the downtime happened.

Third-party dependencies are your outage from a customer's point of view, whoever caused it. 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. The automation should prompt and prepare, and a person decides what is said.

What to build first

Build 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. The automation is small, it removes the worst version of an outage for customers, and it costs nothing when nothing is wrong.

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

Frequently asked questions

What does "up" actually mean?

"Up" means a customer can complete their journey, so measure availability 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 you can send, because customers then lose trust in later notices.

How often should we update during an incident?

Update 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 the problem, and a regular update shows customers that someone is.

Why tell support first?

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. Support can then answer the first ticket consistently, and the later ones in the same way.

Where should the status page be hosted?

Host the status page 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. Use a separate provider or domain, and check that the page loads when your main systems are down.

What should the incident record capture?

The record should 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 any review asks for it first. Automatic capture saves the team from reconstructing events from memory.

Is an uptime percentage worth reporting?

Not on its own. A percentage hides when the downtime happened and who it affected, and three nines still permits roughly nine hours a year. Report incidents, durations and affected journeys instead. Each incident then shows when it happened, how long it lasted and which customers it reached.

How should planned maintenance be handled?

Announce it days ahead with what specifically will be unavailable, schedule it by the customer's timezone rather than yours, suppress alerting for the window automatically and confirm when it finishes. Customers can then plan around the window and know exactly when the service is back.

What gets forgotten about maintenance windows?

The completion notice. People plan around the window and then cannot tell when it is over, so they wait longer than necessary or check repeatedly. The notice takes one line and is almost always missing. Send it automatically when the work ends, even if the work finishes early.

Related reading

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