Alerts
Email your team when traffic drops, a goal moves or errors pile up in an hour, compared with what is usual for that hour.
An alert emails your team when an hour on your site is well away from what is usual for that hour: traffic falls off, a goal stops converting, or errors and failures pile up. You set them up once, and Little Friend checks every hour. A quiet site never pages, and one problem sends one email, then one more when things are back to normal.
What an alert watches
- Traffic drop (
traffic_drop): Page views or visits well below the usual for the hour. - Goal change (
goal_spike): A goal's completions well above or below the usual for the hour. - Error spike (
error_spike): An error group that is new or well above its usual count. - Failure spike (
failure_spike): A problem event or a lower-is-better goal well above its usual count.
Every alert counts people, never bots or agents, on every platform. A traffic drop counts page views or visits. A goal change watches one goal and fires when it falls, rises or either, as you choose. By default it watches for the bad news: fewer completions of a normal goal, more of a goal that counts a failure. An error spike watches JavaScript errors and failed requests, so it needs error capture on. A failure spike watches problem events and goals that count a failure.
What counts as usual
Each alert looks at the last complete hour, about 10 minutes after it ends so late events are counted. It compares that hour with the usual for it: the median of the same hour, on your project's clock, on the 7 days before. Daylight saving changes move the comparison with the clock. A drop or a rise must also hold against the same hour a week earlier, so a quiet Saturday is not a drop next to a busy week, and a job that fails every Monday morning is usual for a Monday.
An alert waits until it has at least 3 days of history. A JavaScript error or failed request seen for the first time in the hour can fire before that, once it happens often enough.
Sensitivity
Each alert has a sensitivity. Low fires on big changes only. High also fires on smaller ones, and on smaller sites. Nothing fires below the minimum volume, however steep the change, and nothing fires on a change that ordinary hour-to-hour noise would explain.
| Sensitivity | A drop fires at | A rise fires at | Traffic drop needs a usual of | Goals, errors and failures need | A new error fires at |
|---|---|---|---|---|---|
| Low | 70% of the usual or less | 5 times the usual or more | 100 an hour | 50 an hour | 10 in its first hour |
| Medium | 50% of the usual or less | 3 times the usual or more | 30 an hour | 20 an hour | 3 in its first hour |
| High | 30% of the usual or less | 2 times the usual or more | 10 an hour | 10 an hour | 1 in its first hour |
For a rise, the minimum is the count in the hour. For a fall, it is the usual count, so a goal that normally completes a handful of times an hour never fires on a fall to zero.
Set one up
In the dashboard, open Settings, Alerts. Pick what to watch and a sensitivity, and choose who gets the email. A project can have up to 20 alerts. Editors and owners create, change and delete them. Anyone in the workspace can see them and their history.
Or from the terminal, with the Little Friend CLI:
littlefriend alerts create --kind traffic_drop --metric visits --sensitivity medium
littlefriend alerts create --kind goal_spike --goal <goal id> --change fall
littlefriend alerts create --kind error_spike --subscriber <email>littlefriend alerts list
littlefriend alerts update <alert id> --sensitivity high
littlefriend alerts update <alert id> --off
littlefriend alerts update <alert id> --subscribe
littlefriend alerts delete <alert id> --yes
littlefriend alerts history --limit 20--off pauses an alert and --on turns it back on. Deleting an alert keeps the alerts it already sent in the history. The history lists up to 200 at a time, newest first. See the CLI reference for every flag.
Who gets the email
Alerts are emailed only to members of your workspace with a verified email, up to 50 for one alert. Whoever creates an alert gets it unless they choose other people. Editors and owners choose who gets each alert. Any member with a verified email can turn an alert on or off for themselves, with the switch in Settings, Alerts or --subscribe and --unsubscribe. Someone who leaves the workspace stops getting them.
The email names the hour, what moved, its count, the usual and the same hour a week earlier, for up to 5 things at once, busiest first. It links to the project's alerts in the dashboard. Alerts hold counts only, never anything about a visitor.
Keeping the inbox quiet
- One problem is one alert. It stays open while hours keep firing, and closes with one recovery email once it has been back to normal for two hours in a row. A problem that keeps coming and going waits for six normal hours before it is called over.
- After an alert email, the same alert sends no other for 6 hours. A problem that starts again inside that time is still listed in the history. If you got a recovery email in between, you are told it started again.
- One address gets at most 10 alert emails an hour, across every project. More than that wait for the next hour.
- An email that could not go out within 6 hours of the alert is dropped, since it is no longer news. If the problem is over before its email went out, the alert email is not sent.
- An alert on a goal you archive waits and sends nothing until you restore the goal.
History
Settings, Alerts lists every alert that fired, when it started and ended, the counts that set it off and how many of its emails were sent, are waiting or failed. History is kept as long as your project keeps its totals, and goes when you delete the project.