Four events, one routing matrix, templates you control
Every alert in LastPing is one of four events — down,
fail, recovery, every-run —
routed per monitor to any mix of email, Telegram, Slack, Discord, and
signed webhooks, with a per-event message template you can rewrite.
This page is the reference.
The four events
Two open incidents, one closes them, one is a running commentary.
| Event | When it fires | Typical use |
|---|---|---|
| down | The expected signal didn't arrive. Grace window exhausted (cause: silence), a started run that never finished (overrun), or a CI run that never started (never_started). Opens an incident. | The default page-me event for every monitor. |
| fail | An explicit failure signal. A /fail ping, a non-zero /<exit-code>, or a failed CI run. Opens an incident immediately — no waiting for grace. | Jobs that can report their own errors; CI pipelines. |
| recovery | The next success after an incident. Closes the open incident automatically — no manual reset. | The all-clear, to the same channels that got the alert. |
| every-run | Every completed run, success or fail. Only emitted for monitors with a destination subscribed to it. | Positive confirmation and audit trails (see below). |
When to use every-run. For jobs that
run rarely and matter enormously — the weekly billing run, the monthly
report, the quarterly cert rotation — silence-based alerting is
asymmetric: you'd hear about failure, but success is just… quiet.
every-run flips that: a positive "it ran, here's the
outcome" message on every completion. On a monitor that runs every
minute it's noise; on the jobs you'd otherwise double-check by hand,
it's the double-check.
The routing matrix
Per monitor: a destination × event grid. Tick where each event should go.
- Destinations — email, Telegram, Slack, Discord, and signed webhook. Your verified email is attached automatically at signup, so the first alert needs zero setup.
- Mix freely — e.g. down and fail to Slack and email, recovery to Slack only, every-run to a webhook feeding your own audit log.
- Test-send — every destination has a test button, so you verify the pipe before you need it.
- Silent-monitor warning — a monitor with no destination is loudly flagged in the console. A monitor nobody hears is a checkbox, not a monitor.
- Flap damping — a monitor that fails and immediately recovers within the damping window doesn't page you.
Message templates
Each monitor can override the message per event, with a live preview in the console. The default is:
| Variable | Renders as |
|---|---|
| {check_name} | The monitor's name. |
| {status} | Current state: up, late, or down. |
| {event} | The event type: down, fail, recovery, or every-run. |
| {cause} | Why: silence, fail, overrun, or never_started. |
| {last_ping} | Time since the last signal, e.g. "2m ago". |
| {schedule} | The human-readable schedule, e.g. "every 1h". |
| {incident_url} | Deep link into the console. |
| {run_url} | Link to the CI run (CI monitors). |
| {branch} | Git branch of the run (CI). |
| {commit} | Short commit SHA (CI). |
| {actor} | Who triggered the run (CI). |
| {failing_stage} | The failing job or stage (CI). |
| {duration} | Run duration — from a paired start/success or the CI run. |
| {latency} | Probe latency in ms (HTTP monitors). |
| {status_code} | Probe HTTP status (HTTP monitors). |
| {url} | The probed URL (HTTP monitors). |
Example — a CI failure template that tells the on-call everything before they click:
Templates pair with the guides: wire the signals with cron, GitHub Actions, or an HTTP monitor, then shape what lands in the channel here. Browse all guides.
An alert should read like a briefing, not a riddle.
Events, routing, and templates are all free — and LastPing monitors itself the same way.