The problem: an alert nobody sees is the same as no alert
A monitor can detect that your site has stopped responding, that a nightly backup did not run, or that a cron job has gone quiet. None of that helps if the message lands in an inbox nobody opens until Monday.
For a solo developer, the question is simple: where do you want to hear about it first? For a team of two or three, it is harder. Someone has to be the person who gets the message, and someone else has to be the person who gets it when the first person is asleep, on a train, or on holiday.
So the choice of alert destination is not a technical detail. It decides how quickly a problem reaches someone who can act on it. This post covers the three routes AperioFlow offers today, what each one is good for, and a simple plan you can copy.
Email: good for the record and for people who are not at their desk
Email is the most familiar route. Every alert is written down in a message you can search later, forward to a client, or attach to a note about an incident. That record matters when you need to work out what happened at 2am last Tuesday.
Email is also the route that reaches people who are away from their laptop. It will not interrupt a meeting in the way a phone call does, and it will not pop up on a screen you are not looking at. That makes it a good fit for the record and for the second or third person on your list.
Alert emails go only to people in your organisation. You choose who is in it, so an alert about a client's shop does not go to a stranger or to someone who has left the team.
Do not rely on email alone for anything that needs a reply within minutes. Treat it as the reliable copy, not the fastest one.
Web push: good for the person on call who has a browser open
Web push sends a notification to a browser that has already given permission to receive them. If the person on call has AperioFlow open in a browser tab, or has allowed notifications for the site, the alert appears on their screen as it happens.
This suits the person who is working at a desk for most of the day. It is quicker to notice than an email that sits in a crowded inbox, and it does not need anyone to check a separate app.
The limit is obvious. Web push depends on a browser being available and permission being granted. If someone closes the laptop, or uses a browser where notifications are blocked, the alert will not reach them that way. That is why web push works best as one route among several, not as the only one.
Webhooks: send the alert to a place your team already watches
A webhook sends the alert to an address you choose, as a message that another system can read. The most common use is a chat room your team already keeps open all day. Another is a small script you wrote yourself, which might restart a service, post to a log, or open a ticket.
Webhooks suit teams that already have a habit of watching one place. If everyone reads the same chat room during working hours, the alert arrives where people are already looking. If you run a script, the alert can trigger a first response without anyone having to read it.
The trade-off is that a webhook is only as useful as the thing at the other end. If the chat room is muted, or the script fails quietly, the alert goes nowhere useful. Check that the destination is one people really read, and test it, as described below.
A simple routing plan for a team of three
Here is a plan that works for a small team. Adjust the names to suit.
- Person A (primary) gets web push while at a desk, and email as the record.
- Person B (backup) gets email, and a webhook to the team chat room.
- Person C (third) gets email only, and sees anything that has been open for longer than an hour, because it has not been picked up.
The rule is that every alert reaches at least two people by two different routes. The primary sees it fastest. The backup sees it if the primary does not respond. The third person is there for the record and for the case where both are unavailable.
Write the plan down. A short note in your team's shared document is enough: which monitors go to whom, who is the backup, and what the backup is expected to do if the primary has not acknowledged an alert within a set time. The plan is only useful if everyone knows it exists.
The free plan includes 10 monitors, so you can start with the sites that matter most and add the rest as you need them. The team plan is £29 a month flat for up to 10 people, as on the pricing page.
Test the route: trigger a test alert and time how long it takes someone to notice
A route you have not tested is a guess. Before you rely on it, run a test.
Pick a monitor that you are happy to fail on purpose, or pause a test one. Trigger an alert and write down the time. Then ask each person on the route to tell you when they see it, and note the time they report. Do this for each route, not just for the one you use most.
You will usually find one of three things. The alert arrives fast on web push, but the email takes ten minutes to land. The chat room is muted on one person's phone. Or the backup has never been told they are the backup. Each of these is easy to fix once you know about it.
Repeat the test once a month, or after you change anything about the routing. Keep the times in your notes. If the gap between the alert and someone noticing keeps growing, that is a sign the route needs attention, not that the monitor is wrong.
Review the list when someone joins or leaves the team
Routing plans go stale. A new person joins and nobody adds them. Someone leaves and their address still receives alerts about a client they no longer work on. Both are common, and both cause trouble at the worst moment.
Make the review part of joining and leaving. When someone joins, decide which routes they take, add them, and run a test alert with them. When someone leaves, remove them from every route on the same day, and check that the backup role has moved to someone else.
It takes about ten minutes each time. It saves a great deal of confusion later.
What a message should say so it can be read at a glance
Whichever route you choose, the message itself decides how fast someone can act on it. Aim for three things that a person can read in a second:
- The monitor name. Use the name that tells you which site or job it is, such as "Client shop checkout" rather than "Monitor 4".
- What failed. Say whether the site did not respond, returned an error, or the job did not check in on time.
- Since when. A time, not a vague phrase. "Down since 02:14" tells you far more than "recently".
If the message gives you those three things, you can decide in seconds whether to act now or wait. If it does not, you will spend the first minute working out what the alert is about.
Start with one route and one monitor
You do not need to set up every route on the first day. Pick the one that matches how your team already works, add one monitor, and test it. Then add the second route and the backup.
Start free at https://app.aperioflow.co.uk/#/signup. Add a monitor, then set up the alert route you chose, and run a test alert before you rely on it.
Run from the UK. You can download your data.