A channel full of red and green
The uptime monitor posts to a Slack channel: site down, site up, site down, site up. Most are blips of a minute when a server restarts or a scan runs. The team learned to ignore the channel months ago. When a client's online shop goes down for real on a Saturday morning, the alert sits between dozens of others.
The client finds out from a customer and emails the studio owner at lunchtime. By the time anyone looks, the site has been down for hours. The client's maintenance plan includes monitoring, which makes the conversation on Monday particularly uncomfortable.
Why alerts get ignored
- Every blip triggers an alert, so real outages look the same as noise.
- Alerts go to everyone, which means they go to no one in particular.
- Nobody has recorded who is responsible for which site, or what the client's plan includes.
- Out of hours, there is no agreed arrangement for who looks and when.
- Once an alert is seen, there is no record of who picked it up and what they did.
Monitoring tells you that a site is down. It does not decide who should care, and that is where the process breaks.
What missed outages cost
Clients lose business while their site is down, and the agency looks like it was not watching, even though it was paying for monitoring. Clients on the cheapest plan get the same attention as clients on the premium plan, or neither get enough. After an incident, the agency cannot tell the client what happened because nothing was recorded.
The alert routing we build
- Every monitored site is linked to its client, hosting location, plan and responsible developer, with a backup.
- Alerts from your uptime tool, such as UptimeRobot, Better Stack or your host's monitoring, are received by the routing service rather than posted straight to a channel.
- Short blips are held briefly and the site is rechecked from other locations. Only confirmed outages become incidents.
- Incidents are sent to the responsible developer by the channel your plan terms call for, and escalate to the backup if not acknowledged.
- Where several sites on the same server go down together, they are grouped as one server incident, so the cause is obvious.
- Each incident records when it started, who acknowledged it, what was done and when it ended, and can generate a short note to the client.
- Incidents appear in the client's maintenance report automatically.
| Event | What happens |
|---|---|
| Short blip | Rechecked, logged, no alert |
| Confirmed outage on one site | Responsible developer alerted |
| Several sites on one server down | Grouped as a server incident |
| Not acknowledged | Escalated to the backup |
| Resolved | Incident closed, client note drafted |
What response you offer out of hours is your commercial decision. The routing follows whatever your plans say, and makes sure it is actually done.
Saturday with routing in place
The shop goes down. The monitor sees it, rechecks from two other locations and confirms it. The developer on call for that server gets a message, sees that three sites on the same server are affected, and contacts the host. When the sites come back, the incident closes and a note is drafted to each client explaining what happened. On Monday, the client already knows.
Are your uptime alerts working for you?
- Uptime alerts go to a channel or inbox that everyone ignores.
- Clients have reported outages before you noticed.
- Nobody is named as responsible for each site.
- Blips and real outages look the same.
- Incidents are not recorded for client reports.