Monitoring
Status Pages
Pricing
In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear.
There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce.
When teams don’t explicitly decide what they want to happen as a result of a signal, they default to the loudest option available. Over time, that choice creates noise, confusion, and disengagement; even when the underlying intent is reasonable.
A useful question to ask of any alert is simple:
What do we expect someone to do when they receive this?
If the answer is unclear, or if the answer is “nothing, really”, then what you’re designing is not an alert. It’s something else, visibility, reassurance, reporting, or record-keeping; and treating it as an alert will eventually undermine all of those goals.
After many years of working with engineering teams, one pattern shows up again and again. Alerts are often used to solve problems they were never designed to address.
It’s common to see alerts sent to managers, directors, or wider stakeholder groups “to keep them in the loop”.
The motivation is understandable. People want to know when there’s been downtime, when customers might be affected, or when something went wrong overnight. But if the recipient is not expected to act, then an alert is the wrong tool.
Repeated exposure to signals that don’t require action teaches people a very specific lesson; that this can be safely ignored.
At first, they skim. Then they mute. Eventually, they unsubscribe or mentally filter the message entirely. At that point, even genuinely important signals struggle to cut through.
The failure here isn’t one of discipline. It’s a mismatch between the signal and the outcome it’s trying to achieve.
High-performing teams tend to make a clear distinction between different kinds of information, based on what they want to happen next.
Some signals exist to prompt immediate action.
Others exist to provide situational awareness.
Others exist to support reflection and learning over time.
Alerts are appropriate for the first category only.
If no action is expected, then interruption is a cost with no corresponding benefit. In those cases, mechanisms like status pages, dashboards, or periodic reports are usually far more effective. They provide visibility without demanding attention, and they build trust rather than fatigue.
Clarity here doesn’t reduce transparency. It improves it.
When alerts are explicitly designed for action, several things become easier.
Ownership becomes clearer, because someone is expected to respond. Content becomes sharper, because only information relevant to that response is included. And escalation paths become simpler, because the system knows what should happen next if nothing happens.
Crucially, alerts designed this way don’t need to go to many people. They need to go to the right one. That can feel risky at first, especially for teams used to broadcasting widely. Over time, it creates calmer responses, faster decisions, and far less noise.
The system stops asking people to interpret intent, and starts supporting them in acting.
None of this is about using the “right” alerting product or platform. It’s about being disciplined in how signals are designed.
Before adding a new alert, it’s worth pausing to ask:
If those questions can’t be answered clearly, then the signal probably shouldn’t be an alert.
Designing for outcomes doesn’t just reduce noise. It restores trust in the signals that remain.
In the final post of this series, we’ll bring these ideas together and look at alerting as a socio-technical system. This is a system that encodes assumptions about responsibility, confidence, and how people behave under pressure.
Share this
7 min read A website may be standing and still be in trouble. It may answer a request, return a cheerful 200 OK, and yet load slowly enough that visitors begin to lose patience. Its certificate may be nearing expiry. Its domain records may have changed. A server may be filling its disk in the background, patient and
6 min read StatusCake tells you that something might be broken. Hermes can check whether it really looks broken, decide who should hear about it, send the email, and keep the record for tomorrow morning’s summary.
3 min read The allure of OpenClaw is undeniable. You deploy a highly autonomous, self-hosted AI agent, give it access to your repositories and inboxes, and watch it reason through complex workflows while you sleep. It is the dream of the ultimate 10x developer tool realized. But as any veteran DevOps engineer will tell you: running an LLM-backed
7 min read There are cloud outages, and then there are us-east-1 outages. That distinction matters because failures in AWS’s Northern Virginia region rarely feel like ordinary regional incidents. They tend instead to expose something larger and more uncomfortable: too much of the modern internet still behaves as though one place is an acceptable concentration point for infrastructure,
7 min read Artificial intelligence is making software easier to produce. That much is already obvious. Code that once took hours to scaffold can now be drafted in minutes. Boilerplate, integration logic, tests, refactors and small internal tools can be generated with startling speed. In some cases, even substantial pieces of implementation can be assembled quickly enough to
10 min read Whilst AI has compressed the visible stages of software delivery; requirements, validation, review and release discipline have not disappeared. They have been pushed into automation, runtime and governance. The real risk is not that the lifecycle is dead, but that organisations start acting as if accountability died with it. There is a now-familiar story about
Find out everything you need to know in our new uptime monitoring whitepaper 2021
