Report heartbeats from jobs and scripts

Set PINGSTACK_PING_URL using the secret location URL copied from the app. Store it in the scheduler’s private environment or CI secret store. These recipes assume you have already created a heartbeat check.

Success-only shell job

your-job && curl --fail --silent --show-error "$PINGSTACK_PING_URL"

The heartbeat runs only after exit zero. If your wrapper hides failures or returns early, a healthy check can misrepresent the work.

Record diagnostics without claiming exit-code alerting

curl --fail --silent --show-error \
  --request POST --header 'Content-Type: application/json' \
  --data '{"records_processed":1200}' "$PINGSTACK_PING_URL"

Use after completion to retain a diagnostic payload. Sending exit_code=1 records the code but still marks the location up; it is not a failure signal. Do not send a heartbeat on failure when your intended signal is successful work.

Cron and CI

Run the success-only wrapper from cron, with the URL supplied privately to the wrapper environment. Match the check’s cron expression and timezone to your job, and account for runtime with grace.

In CI, use a final success-only step for the task being monitored, reading the URL from the platform’s secret mechanism. Avoid printing the expanded command or URL. A workflow running only on code changes is not necessarily a regularly scheduled job; choose a heartbeat expectation consistent with actual runs.

Numeric signal

curl --fail --silent --show-error \
  --get --data-urlencode 'value=42' "$PINGSTACK_PING_URL"

For queue depth, choose above warning/critical values. For free capacity, choose below. Both thresholds are required, and equality counts as a breach. This is evaluated alongside check-in timing, not instead of it.

Give independently expected senders their own named locations. Sharing one URL lets one successful sender hide another sender’s silence.