Your first hour
Connect one real source, see real data, write one alert, and get paged by it — end to end.
This walks the whole loop once with real data. It takes about an hour, most of which is waiting for the first readings to arrive.
You need the admin role for steps 1 and 2. If you only have engineer, ask
an admin to do those and start at step 3.
1. Connect something that produces data
Pick whichever of these you already have. One is enough to finish the tour.
Services is the shortest route:
- Go to Monitor → Services → Add service.
- Give it a name, a URL, and an environment.
- Set the check interval. 60 seconds is a sensible default; below 30 seconds you are mostly measuring your own checker.
- Save.
Within a minute the service shows a status and a response time. If it does not, the service detail page says what the check returned — it will not show a blank card and leave you guessing.
2. Add one notification channel
Incidents & On-Call → Channels → Add channel.
Slack is the usual first one. Paste an incoming-webhook URL, name it something
a stranger would understand at 3 a.m. (#ops-alerts, not webhook 2), and
pick a kind:
| Kind | Gets |
|---|---|
alerts | Alert fired / recovered |
incidents | Incident opened / updated / resolved |
| both | Everything |
Press Test before you leave the page. A test message proves the webhook, the network path and the formatting all work — while you are still looking at the screen, rather than during the first real incident.
Name channels after the audience, not the transport. #payments-oncall tells
the next person who reads the routing rules something; slack-2 does not.
3. Write one alert rule
Go to the thing you connected and add a rule. For a service:
Monitor → Services → (your service) → Rules → Add rule.
Set it to something that will definitely fire, so you can see the whole path:
- Condition: response time above
1ms - For:
0minutes - Severity:
warning - Channel: the one you just made
Save it, and wait for the next check.
4. Watch it fire
You should get a message in Slack within a check interval or two. Then look at Incidents & On-Call → Alerts — the alert is there with its severity, its fingerprint, and a delivery panel showing which channels it went to.
If the message did not arrive, the delivery panel says why. That page is the answer to "did the page go out?" and it distinguishes four different answers:
| What it says | What it means |
|---|---|
| Delivered | The channel accepted it |
| Retrying | It failed, another attempt is scheduled, the page shows when |
| Gave up | Every automatic attempt failed — press Retry |
| (nothing) | No channel matched the routing — check the channel's kind |
5. Make it recover
Change the threshold to something sane (response time above 2000 ms). On the
next check the condition is false, the alert recovers, and — if your channel is
configured for it — you get a recovery message.
Recovery requires a measurement that finds the condition false. If the service stops responding entirely, the alert does not recover; it stays open. An absent reading is not a good reading. This is true everywhere in AccelerUp and it is the behaviour you want at 4 a.m.
6. Now make it useful
You have proved the loop. The next three things are what turn it into real monitoring:
- Set
Forto a non-zero value.For: 5means "five minutes of this before you tell anybody" and removes most transient noise. - Set an escalation policy. A channel is a broadcast. An escalation policy pages a person, and pages the next one if nobody acknowledges.
- Put it on an on-call schedule. On-call decides who that person is at 4 a.m. on a Sunday.
Where to go next
- How alerting works — the full model: conditions, for/recovery, cooldown, fingerprints, grouping.
- Core concepts — if any word above was unfamiliar.
- SQL alerts — alert on anything you can write a query for. This is the most powerful part of the product.
Part of Getting started — What AccelerUp is, the words it uses, and the first hour with it.