Why the first report from a user is usually the slowest alert you have
A user who emails you about a broken page has already waited. They saw the error, decided it was worth their time, found your contact details and wrote a message. By the time it reaches you, the problem may have been live for hours, and some of your users will have left without saying anything.
If you run a web app or a client site on your own, you are probably the only person who gets the message when something breaks. That makes the first report the least useful alert you have. The aim of a small setup is simple: you hear about a new error from your own system, before anyone else does.
What to send to AperioFlow: unhandled exceptions, failed background tasks and failed requests
Start with three kinds of error. They cover most of what goes wrong in a small app.
Unhandled exceptions come first. These are the errors your code did not expect and did not catch. They are the ones most likely to show a blank page or a spinner that never stops.
Failed background tasks come second. Sending invoices, resizing images, syncing data and sending reset emails often run outside the request a user makes. When they fail, nothing appears on screen, so the failure can sit unnoticed for days.
Failed requests come third. These are calls that return an error status, such as a server error from your own API or a third-party service that your app depends on. A single failed request may be harmless. A pattern of them usually means something has changed.
You do not need to send every log line. Send the errors that would make a user's day worse if you missed them. You can add more later once you know what is noisy.
Setting an alert rule that tells you about a new error, not every repeat
An alert rule that fires on every occurrence will teach you to ignore your inbox. Set the rule to alert you when an error appears for the first time, or when a known error starts happening again after a quiet period. Repeats of an error you already know about can wait in the list until you look at it.
Repeated errors are grouped so that one problem shows up as one item with a count, not as a hundred separate messages. We cover how grouping works in our post on grouping repeated errors, so we will not repeat it here. For setup, the only thing to decide is whether a new error should alert you straight away. For most small teams, the answer is yes.
Check the rule after the first day. If you received an alert for something you would have happily ignored, tighten the rule or filter that error out. If you received no alerts at all and you know something broke, widen it. Ten minutes of adjustment in the first week saves a lot of noise later.
Deciding who gets the alert email: only people in your organisation
Alert emails go only to people in your organisation. Decide that list before the first error arrives, not during an incident.
For a solo developer, the list is one person. For a freelancer who runs client sites, it may be you plus a second person who can respond if you are away. For a small agency or product team of up to 10 people, pick two or three people who take turns, rather than sending everything to a shared inbox that nobody owns.
Write the list down in your team notes. Include who is on call this week and what they should do if they cannot respond within an hour. A list that is clear on paper is far easier to follow when something breaks at a bad time.
What to do in the first ten minutes after an alert: read, reproduce, assign a task
When the alert arrives, do three things in order. Resist the urge to start changing code straight away.
First, read. Open the error and look at what it says, where it happened and when it first appeared. Check whether it is a new error or a repeat. Note which page, request or background job was involved. Five minutes of reading often tells you whether this is a one-off or the start of an outage.
Second, reproduce. Try to trigger the same error yourself, in a copy of the app or a staging environment if you have one. If you can reproduce it, you can check your fix. If you cannot, note what you tried and move on to the next step.
Third, assign a task. Do not hold the problem in your head. Create a task in AperioFlow, give it a clear title that names the error and the affected part of the app, and assign it to the person who will work on it. Add a line about what you found in the first ten minutes. That way, if you step away, the next person has somewhere to start.
If the error affects users right now, post an update on your status page as well. A short, honest note that you are looking into a problem is better than silence. Keep it to what you know.
Turning a fixed error into a task so it does not come back unnoticed
Fixing an error is not the end of the job. Many errors return after a deploy, a dependency update or a change in a third-party service, and the second time often goes unnoticed because nobody remembers the first.
When you fix an error, create or update a task that records what caused it, what you changed and how you checked the fix. Keep it open until the error has stayed quiet for a reasonable period. Then close it with a short note.
If the same error appears again, the record is already there. You can see the history, what you tried before and whether the cause is the same. That turns a repeat from a surprise into a known item you can handle quickly.
Checking the error list once a week as part of your planning habit
Alerts catch the errors that are new and loud. A weekly look at the full error list catches the quiet ones: the error that fires once a day, the background job that fails on Sundays, the request that times out only for one client.
Make it a fixed part of your planning. Pick the same time each week, perhaps the first half-hour on a Monday, and go through the list. Sort by count and by recency. Check whether each open error still has a task. Close anything that has been resolved for a while and open tasks for anything that needs attention.
For a small team, this is the habit that keeps the setup working. The alerts tell you when something is new. The weekly review tells you what has been quietly getting worse.
Where to start
You can set this up in an afternoon. Connect your first app, send the three kinds of error, set the alert rule to new errors, add the people in your organisation who should receive the email, and write down the ten-minute routine. Then add the weekly review to your calendar.
The free plan includes 10 monitors. Start free at https://app.aperioflow.co.uk/#/signup and connect your first app today.