Server alerting

Server alerting pages your team when a server stops reporting. It works like monitor alerting: when a server goes offline, an outage opens and the escalation policy bound to the server notifies its channels.

Server states

Each enrolled server has a liveness state based on the metrics the agent reports:

• Green. The agent is reporting normally.
• Orange (stale). The first scrape gap has crossed the stale threshold (30 seconds). This is surfaced in the UI only, no alert fires.
• Red (offline). No metrics for longer than the server's offline threshold (default 90 seconds, floor 60 seconds). An outage is opened and the escalation policy bound to the server pages its channels.

Tune the offline threshold

The offline threshold is per-server and tunable from the Alerting panel on the server detail page. Pick something longer than your worst expected network blip, and shorter than you'd want to wait before being paged.

Choose who gets paged

Bind an escalation policy to the server from the same Alerting panel. The policy's steps, delays, and channels apply exactly as they do for monitors: email, SMS, phone calls, Slack, Teams, PagerDuty, OpsGenie, webhooks, or an on-call schedule.

Recovery

When the agent reports metrics again, the outage is resolved and recovery notifications are sent to the same channels.

Testing your setup

To verify alerting end to end, stop the agent on a non-critical server and wait for the offline threshold to pass:

sudo systemctl stop hyperping-agent

You should be paged through the escalation policy bound to that server. Start the agent again to trigger the recovery notification.

Plan availability

Server alerting is included on all paid plans. See pricing for the number of server agents included in each plan.

Next steps

• Install the agent: enrollment, install tokens, and liveness details.
• Metrics collected: CPU, memory, filesystem, disk I/O, and network.
• Escalation policies: configure who gets paged, and in what order.