Know that the backup ran

If your PostgreSQL job uses pg_dump, its custom archive format restores with pg_restore. The command below shows the reporting order. It does not prescribe a production backup design.

Set POSTDEPLOY_INGEST_URL to https://ingest.postdeploy.dev and store the token where the scheduler can read it. The token is a credential. Do not put it in source control or print it in logs.

The /0 path records a successful finish. A non-zero final path segment records a failed run. The wrapper preserves a failed backup exit status. When the backup succeeds but delivery fails, it exits with the curl status so the scheduler records the delivery failure. curl -f makes a 4xx or 5xx response fail the transfer.

#!/bin/sh
set -u

backup_file="/var/backups/app-$(date +%F).dump"

pg_dump --format=custom --file "$backup_file" "$PGDATABASE"
backup_status=$?

curl -fsS --max-time 10 \
  "$POSTDEPLOY_INGEST_URL/h/$POSTDEPLOY_HEARTBEAT_TOKEN/$backup_status"
delivery_status=$?

if [ "$backup_status" -ne 0 ]; then
  exit "$backup_status"
fi

exit "$delivery_status"

A successful dump file may still not be a usable backup if a later upload or encryption step fails. Send the success heartbeat after the last step that makes the backup available where you rely on it.

Warning: upload_backup and verify_backup_object below are placeholders. Replace them with commands that your backup system provides before you run this pattern. Do not place a success ping before the upload. Do not write backup_command; curl ... without preserving the exit status.

# Replace upload_backup and verify_backup_object with your own commands.
pg_dump --format=custom --file /tmp/app.dump "$PGDATABASE" &&
upload_backup /tmp/app.dump "backups/app-$(date +%F).dump" &&
verify_backup_object "backups/app-$(date +%F).dump"
backup_status=$?

curl -fsS --max-time 10 \
  "$POSTDEPLOY_INGEST_URL/h/$POSTDEPLOY_HEARTBEAT_TOKEN/$backup_status"
delivery_status=$?

if [ "$backup_status" -ne 0 ]; then
  exit "$backup_status"
fi

exit "$delivery_status"

A success heartbeat shows that the job reached the reporting line and the endpoint accepted that report. It cannot show that the backup still exists, has the expected contents, meets retention rules, or can restore your application.

PostDeploy has no independent deadline evaluator for a missing finish. A stopped scheduler, an absent first run, or a command that never reaches the reporting line creates no check or incident. Use an external scheduler watchdog where you need missed-run detection.

Run a restore test on a separate schedule and give it its own heartbeat. PostgreSQL documents pg_restore as the tool to rebuild a custom-format archive. The backup job and restore test should have separate evidence because a recent dump is not evidence of a successful recovery.

Run the real backup once and confirm that the completion report appears as a passing check. Then force a harmless failure in a non-production test and confirm that a non-zero exit creates the failed check you expect. Do not claim that stopping the scheduler creates a PostDeploy alert. These checks do not prove recovery until the restore test succeeds.

Keep the HTTP uptime monitor too. It protects the user-facing endpoint. Add the completion heartbeat because the backup is a different failure domain.