Monitor systemd timers: success, failure, and silence

systemd remembers failures. It doesn't report them.

A failed unit sits patiently in systemctl --failed, waiting for a human who isn't coming.

Setup: three unit files

The example monitors a nightly backup; rename to match your job. If curl lives elsewhere on your distro, check with which curl.

https://ping.lastping.dev/<your-monitor-id>

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup
OnFailure=backup-fail.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<your-monitor-id>

# /etc/systemd/system/backup-fail.service
[Unit]
Description=Report backup failure to LastPing

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<your-monitor-id>/fail

# /etc/systemd/system/backup.timer
[Unit]
Description=Run nightly backup at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

# run the service once by hand — the ping should land in the console
sudo systemctl start backup.service

# confirm the next scheduled activation
systemctl list-timers backup.timer

ExecStartPre=/usr/bin/curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<your-monitor-id>/start

What this catches

The units report what they can; the silence reports the rest.

• ✓The service failed: OnFailure pings /fail and you're alerted immediately, journal intact for the post-mortem.
• ✓The timer stopped firing: disabled unit, broken enablement, masked service. No ping in the expected window → incident.
• ✓The machine is down: nothing on the host can report that; the absence of the ping does.
• ✓The job hung: with the /start ping armed, a run that never completes inside grace opens an incident.
• ✓Recovery: the next successful run closes the incident and sends a recovery notice automatically.

Still on classic cron for some hosts? The cron guide is the same pattern in one crontab line. Backup jobs deserve the fuller start → work → success/fail pattern, or browse all guides.

Questions people ask

Front-loaded answers: the most important fact first.

• How do I monitor a systemd timer?

  Add ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<your-monitor-id> to the service unit. For Type=oneshot services, ExecStartPost runs only after ExecStart exits successfully, so the ping means the job actually worked. LastPing expects that ping on the timer’s schedule and alerts when it does not arrive.

• Does ExecStartPost run if the service fails?

  No. For Type=oneshot services, ExecStartPost commands run only after ExecStart has exited successfully. That's exactly the behavior you want: a failed job sends no success ping, and the missed ping (or the OnFailure unit pinging /fail) raises the alert.

• How do I get an immediate alert when a systemd service fails?

  Add OnFailure=backup-fail.service to the [Unit] section, where the referenced unit is a oneshot that curls the /fail endpoint. The explicit failure signal opens an incident immediately instead of waiting out the grace window.

• What if the whole machine is down?

  The timer can't fire and nothing on the host can self-report, but LastPing alerts anyway, because the expected ping never arrives. Absence-based detection is the point: it covers every failure mode, including the ones the machine can't see.

• systemd timer or cron: does it matter for monitoring?

  No. Both patterns end in the same ping to the same URL; systemd just gives you nicer hooks (ExecStartPost, OnFailure) than a shell &&. The cron guide covers the crontab one-liner.

• Is systemd timer monitoring free?

  Yes. LastPing is free for individuals with no monitor cap. See how it compares to Healthchecks.io and Cronitor.