Monitoring

Monitoring turns Atlas from something you look at into something that tells you. You define a target, attach checks to it, and route the resulting alerts to channels.

Requires staff. Everything is scoped to you: your targets, your alerts, your channels. Admins can opt into a cross-user view, but ownership is stamped server-side, so nothing you send can claim to belong to someone else.

Targets

/monitoring · staff

A target is the thing being watched. Four kinds:

Kind	Example
host	a hostname
ip	a single address
prefix	a network block
asn	an autonomous system

The dashboard is a grid of target cards, each showing the target, its tags, and a roll-up status pill. Filter chips across the top narrow by kind, tag or status.

How the roll-up works

A target's status is the worst of its checks, in this order: any check critical makes the target critical; otherwise any warning makes it warning; otherwise any unknown makes it unknown; otherwise it is fine.

Paused and disabled checks don't drag the roll-up down. That is what makes the pause control useful — silencing one check during known maintenance doesn't leave the whole target looking broken.

Tag your targets. Tags are what let you filter a wall of cards down to the ones you care about, and they also gate notification routing (see below).

Checks

Each target carries checks, and which are available depends on the target kind:

Routing — bgp_announce, rpki_status, as_prefix_count, path_stability, as_population_shift

Reachability — ping_loss, traceroute_reach, http_status, dns_resolve

Configuration — tls_cert, anycast_status, geofeed_status

Checks come in two flavours, and the distinction matters:

• Derived checks read data Atlas already collects. They cost nothing extra and run on their own schedule.
• UDM checks run a user-defined measurement on RIPE Atlas — real probes, real credits. Before adding one, be sure you want a standing measurement rather than a derived signal.

Each check has a default interval you can override, and its own configuration.

Alerts

/monitoring/alerts · staff

The alert inbox, in three tabs:

• Open — active and unhandled
• Acked — active, but someone has taken it. Acknowledging does not close the alert; it marks that it is being dealt with.
• Closed — resolved

Per-row actions: ack with a note, snooze for a window you choose, or manually close for known-maintenance cases.

One rule worth internalising: an ok result closes an alert, it never opens one. Alerts are opened by warning and critical results. So an alert that stays open after the underlying problem cleared means no result has landed since — check the interval before assuming the alert is stuck.

Channels

/monitoring/channels · staff

Where notifications go. Three kinds:

• Inbox — created automatically for you and cannot be deleted. It backs in-app alerts. You can disable it to stop them.
• Webhook — a JSON POST with an HMAC-signed payload, so the receiver can verify the notification really came from Atlas.
• Email — SMTP delivery to one or more addresses.

Each channel carries its own tag filter and severity filter. This is the routing mechanism: send everything to your inbox, critical-only to email, and a single tag's alerts to the webhook that opens tickets. Without filters every channel gets everything, which trains people to ignore all of it.

A worked example

Watch a prefix you announce:

1. Create a target of kind prefix, tagged with something meaningful — say production.
2. Add bgp_announce and rpki_status checks. Both are derived: no credits, no measurements.
3. On your email channel, set a severity filter of critical and a tag filter of production.
4. Leave the inbox channel unfiltered, so warnings are visible when you look without waking anyone.

---

Requires staff — see Accounts and roles.