The problem: everyone gets every alert, so everyone assumes someone else has it
When a monitor fails on a team of four, the alert email lands in four inboxes at once. Each person sees it, assumes someone closer to the code will deal with it, and goes back to their work. Ten minutes later the site is still down and nobody has written anything down.
This is not carelessness. It is what happens when the message goes to everyone and nobody is named for it. AperioFlow sends alert emails only to people in your organisation, so the list is already tidy. The gap is in who acts.
The fix is not more alerts or louder ones. It is a habit: one person owns the alerts for a set period, and everyone else knows who that is.
One owner per week: a simple rota for a team of three to ten
Pick one person each week to own alerts. That person is the first to open a new alert, the one who decides what happens next, and the one the others ask when they want to know. The rest of the team still gets the emails, but they know the owner has them.
Keep the rule simple. Rotate in a fixed order so nobody has to ask whose turn it is. For three people, that is three weeks in a cycle. For ten, it is ten weeks, which sounds long but means each person owns the alerts about once a quarter. If your load is heavy, a shorter rotation can work better. Decide once and stick to it for a month before you change anything.
Put the rota in your team's own calendar as all-day events, one per week, with the owner's name in the title. Anyone can check who is on duty without opening AperioFlow.
Write down what the owner does first: open the alert, post an incident update, find the cause
A rota only works if the owner knows what to do in the first ten minutes. Write three steps and keep them short:
- Open the alert and check the monitor. Is this one failed check, or has the site been failing for a while?
- Post an incident update on your status page, even if it only says you are looking into it. Customers would rather read 'investigating' than hear nothing.
- Find the cause, or hand it to whoever can. Note what you have tried so far, so the next person does not repeat it.
Save those three steps in a task called 'Owner steps'. That way they live where the team already works, not in someone's memory or a document nobody opens. Update the steps after a bad week, when you find something you wish you had written down.
Handover: a five-minute note at the end of the week, covering open incidents and noisy monitors
At the end of each week, the owner writes a short handover note. Five minutes is enough. Cover two things: any incidents still open, and any monitor that fired more than it should have.
Put the note in the task for the next owner's week, so it is the first thing they read. It might look like this:
- Open: checkout page slow since Tuesday, cause not found, status page says 'investigating'.
- Noisy: the staging monitor alerts every weekend because the server is switched off on Fridays.
Keep it plain. The next owner should not need to ask you anything to start. If the note is longer than five minutes to write, the team probably has too many open problems, and that is worth raising in your planning.
Fixing the noise: after each week, change or remove one alert that was not useful
Alert fatigue is how a rota fails. If most alerts are false, people stop reading them, and the one real alert gets lost. So after each week, the owner changes or removes one alert that did not help. Only one. Small changes add up, and a big clean-up tends to never happen.
Ask three questions about each alert that fired. Did it lead to action? Did it fire when the site was actually down? Did it fire when nothing was wrong? If the answer to the last question is yes more than once, adjust the check, change the threshold, or stop watching that thing for now. Write what you changed in the handover note so the next owner knows why the alerts look different.
The goal is not zero alerts. It is alerts that people still read.
Keep the rota in the same place as your tasks so it does not live in someone's head
A rota that exists only in one person's head breaks the first time they are ill or on holiday. Put the rota, the owner steps and the handover notes in the same place you plan the rest of the work. In AperioFlow, that is tasks. Each week gets a task with the owner's name in the title, and the handover note sits underneath it.
That way, whoever picks up the work next sees the history without asking. It also helps in planning meetings: if the same monitor appears in three handover notes, that is a task in itself, and it can go into the next sprint like any other piece of work.
Your information stays yours. You can download your data at any time, so the record of who owned what is never locked away.
A short example rota for a team of four
Four people share the alerts: Asha, Ben, Chloe and Dev. Each owns one week in order, so the cycle repeats every four weeks.
- Week 1, Asha owns alerts. Handover to Ben. Change made: the staging monitor stops alerting on weekends.
- Week 2, Ben owns alerts. Handover to Chloe. Change made: the response time threshold on the search page is raised, because it was firing during a known slow batch job.
- Week 3, Chloe owns alerts. Handover to Dev. Change made: a heartbeat monitor is added to the nightly database backup, so a backup that does not run alerts the team.
- Week 4, Dev owns alerts. Handover to Asha. Change made: an alert on a page nobody has visited since last year is removed.
After four weeks, every person has owned the alerts once, and the noise has dropped by four changes. The next cycle starts with Asha, who already has the handover note from Dev.
If you want to try this with your own team, Start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors. For a team of up to 10 people, the Team plan is 29 pounds a month flat, as on the pricing page.