Support  /  Configuring alerts

Configuring alerts

Get told the moment one of your own links leaves its baseline — in Slack or by webhook. Email is coming soon. Alerting watches the paths you measure, on the same scale the dashboard already colours.

What alerting watches

Alerting runs on your links only — the site-to-site paths and targets measured from your own probes. It never watches the global fleet, and it is entirely separate from any status page you follow.

Each link is judged against its own history, not a fixed number. We learn what normal looks like for every link, and raise an alert when it moves far enough off that norm, or stops answering altogether.

The scale an alert fires on

Sensitivity is expressed as milliseconds added over the link's trended norm — the same bands you see on the dashboard:

You pick the band an alert fires at, and a separate packet-loss threshold. Set it looser for a noisy consumer link, tighter for a circuit you expect to be flat.

Turning it on

1. Open your Customer dashboard and sign in.
2. On the Alerts panel, click Configure — or open the Alerting section in the settings rail.
3. Choose which links to watch. You can watch all of them or a subset.
4. Set the sensitivity band and loss threshold from the table above.
5. Add a channel (below) and, if you want, quiet hours.
6. Save. Alerting starts on the next measurement cycle.

Channels — where alerts go

Slack

Create an incoming webhook in your Slack workspace and paste its URL into the channel field. Each alert arrives as a single message naming the link, its reading against baseline, and when it started. This is the fastest channel to set up — no account configuration on our side.

Webhook

Give us any HTTPS endpoint and we POST a JSON payload for each alert and each resolution. Use it to page your own tooling, open a ticket, or fan out to a system we don't integrate with directly.

Email

Recipients who are members of your account confirm automatically; anyone else confirms by clicking a link we email them once, so an alert is never sent to an address that didn't opt in. Email delivery is not switched on yet — the email option stays greyed out until it is. Use Slack or a webhook in the meantime, or ask [email protected] to switch it on.

Quiet hours

Set quiet hours in your own timezone. Alerts that occur inside them are held, not dropped — they are delivered when the quiet window ends, so an overnight problem is waiting for you in the morning rather than lost.

Why it won't flood you

Alerting is built so a single event is a single message, and so a reading has to earn its way to your screen:

• A reroute that settles at a worse-but-steady level won't keep re-alerting, and can't quietly "recover" on its own.
• A flapping link is summarised as one notice, not a message per bounce.
• Too little data stays quiet. A link we haven't measured enough yet, or a destination that has never answered, produces no alert — an unknown is reported as unknown, never as a fault.
• Accept as new normal. When a change is expected — you moved a circuit, a carrier re-homed you — mark it and the baseline resets. Otherwise the link re-learns its own normal over time and the alert clears.

Muting

Planned maintenance on a site? Mute that link for the window. Muting suppresses delivery without deleting the policy or losing history — the link is still measured, you just aren't paged about it.

What an alert tells you

Every alert names the link, its current reading against its own norm (milliseconds over baseline, and loss if that crossed), and when it started. When the link returns to normal you get a matching resolved message, so an open alert always has a close.

Next: back to all guides  ·  How our probes measure