Monitor GitHub Actions, and get told why a run failed

Create a CI check in LastPing

In the console, create a monitor, choose CI pipeline, and pick GitHub Actions. Give it the same schedule as your workflow (e.g. daily with a grace window) so a run that never starts is caught too. Copy the webhook URL and the one-time secret shown on screen.

https://ping.lastping.dev/ci/github/<check-id>

Register the webhook in your repository

On GitHub: Settings → Webhooks → Add webhook.

• Payload URL: the webhook URL from step 1
• Content type: application/json
• Secret: the one-time secret from step 1
• Events: "Let me select individual events" → tick Workflow runs and Workflow jobs (untick the pre-selected Pushes)
• Why both? workflow_run tells LastPing the run failed; only workflow_job carries per-step conclusions, so it is the sole source of the failing step name in your alert. Skip it and alerts read "failed on main" instead of "failed at Run make test on main". Job events never count as extra runs.

Done: every run now reports in

LastPing verifies each delivery's HMAC signature against your secret, then classifies the run: success, failure, started. Branch and workflow filters let you count only the runs you care about (say, main and the workflow named nightly-backup). A filter only counts exact matches, so a moved default branch can leave a branch filter matching nothing. When the filters keep ignoring finished runs and none has matched since they were set, the monitor's Overview says so, counts the ignored runs, names the last one and links to the filters; if every ignored run belonged to another workflow, it says the monitor is waiting for the first run of yours and that the workflow name has to match exactly. It also speaks up when the last match is more than 72 hours old and runs of the monitor's own workflow have been ignored on other branches since; runs of other workflows, which a repository webhook also sends, are the filter doing its job and do not raise it. If your workflow has not run for 72 hours while a workflow name that first appeared after its last match has run at least twice, the Overview flags a likely rename and names the new workflow. A rename is flagged only after a monitor's first 7 days, and one made before this check existed is not flagged after the fact; a scheduled monitor still alerts when its runs stop arriving. Alerts go to email by default (your verified address is attached automatically) and to Slack, Discord, Telegram, ntfy, Pushover, Microsoft Teams, Google Chat or a signed webhook if you add them.

Optional: attach the failure reason to the incident

One if: failure() step POSTs a log excerpt (up to 64 KB, plain text) to the check's detail endpoint. It's stored on the open incident and shown in the console, so the alert doesn't just say "it broke," it shows why. The body is never logged server-side.

LASTPING_CI_SECRET is the same CI secret this monitor's webhook signs with: open the monitor in the console, go to its CI settings and reveal the secret (the reveal is password-gated), then save it as a repository secret alongside LASTPING_CHECK_ID. Sending it also lifts the throttle: without the token, detail posts are limited to 60 per 15 minutes per monitor; with it, there is no limit.

The trailing || true is not decoration: this step only runs on a job that has already failed, and a hiccup reporting the failure (a rate limit, a deleted monitor) must never be what turns the job red a second time.

# optional last step of any job in the workflow
- name: Report failure detail to LastPing
  if: failure()
  env:
    LASTPING_CI_SECRET: ${{ secrets.LASTPING_CI_SECRET }}
    LASTPING_CHECK_ID: ${{ secrets.LASTPING_CHECK_ID }}
    DETAIL: ${{ github.workflow }} / ${{ github.job }} failed on ${{ github.ref_name }} — run ${{ github.run_id }}
  run: |
    curl -fsS -X POST -H "Content-Type: text/plain" \
      -H "X-LastPing-Token: $LASTPING_CI_SECRET" \
      --data "$DETAIL" \
      "https://ping.lastping.dev/ci/$LASTPING_CHECK_ID/detail" || true