1. Create the heartbeat
Add a monitor with Check type Heartbeat (cron). Set the interval to the backup schedule (86400 seconds for a nightly job) and the grace to how long a backup can take. Copy the ping URL shown once after saving and keep it in the job's environment as PING_URL. Heartbeats are on every plan, Free included.
2. Ping on success, report failure with the exit code
In the script or crontab line that runs the backup: restic backup /data && curl -fsS -m 10 "$PING_URL" || curl -fsS -m 10 --data-raw "restic exit $?" "$PING_URL/fail". The success ping is sent only when restic exits 0. Any other exit code marks the monitor down at once with run-failed wording, and the exit code is kept with the failure.
3. Know what the exit codes mean
restic's documentation lists 0 as success, 1 as a failed command, 3 as a backup that could not read some source data (a snapshot was still written), 10 for a missing repository, 11 for a lock it could not take, 12 for a wrong password and 130 for a cancelled run, and says any unknown code must be treated as a failure. Exit 3 is a partial backup: the recipe above reports it as a failure on purpose, so unreadable files do not go unnoticed.
4. Cover forget, prune and check too
A backup that succeeds into a repository that is never checked can still fail on restore. Give restic forget --prune and restic check their own heartbeat with a weekly interval and the same two-line pattern, so a repository problem alerts before you need it. Add "$PING_URL/start" before the backup to see how long each run takes.
Go deeper
The full reference lives in the docs: Heartbeat monitors documentation. Error codes named above are each explained in the error-code reference.