GitHub Actions to On-Call

Failed GitHub Actions workflow runs become CallHeim alerts: repeats on the same workflow collapse onto one incident, and the service the integration is bound to pages whoever is on call for it. CallHeim includes a payload mapping for GitHub Actions’s webhook format, built and tested against sample payloads. Unlike most sources in this catalogue, GitHub signs its webhook natively in a header and format CallHeim already verifies — no custom-header workaround needed to turn signing on.

How the alert reaches on-call

Step 1A GitHub Actions workflow run in your repository changes state: requested, in progress, or completed.
Step 2GitHub's workflow_run webhook POSTs the run, its workflow and its repository to your CallHeim ingest URL over HTTPS.
Step 3CallHeim reads the run's conclusion (success, failure, cancelled, timed_out, …) and maps it to a severity; a run that has not completed is stored as informational regardless of any later conclusion.
Step 4Repeats of the same workflow in the same repository within five minutes collapse onto one incident — the per-run id and run number are not part of the identity.
Step 5The integration's bound service selects an escalation policy, which pages the on-call tier.

Setting it up

01
Create the GitHub Actions integration in CallHeim to get an ingest URL.
02
In the repository (or organisation), go to Settings > Webhooks > Add webhook.
Paste the ingest URL into Payload URL and set Content type to application/json.
03
Under "Which events would you like to trigger this webhook?", select "Workflow runs" individually.
The default "Just the push event" sends nothing CallHeim can read here — you need the workflow_run event specifically.
04
Set a Secret on the GitHub webhook and turn signing on for the CallHeim integration, if you want requests verified.
GitHub signs every delivery with HMAC-SHA256 over the raw body using this secret, sent as X-Hub-Signature-256: sha256=<hex digest> — the exact header and format CallHeim checks (see Security below).

Example payloadJSON

{
  "action": "completed",
  "workflow_run": {
    "id": 5551212,
    "name": "CI",
    "head_branch": "main",
    "status": "completed",
    "conclusion": "failure",
    "html_url": "https://github.com/acme/web-store/actions/runs/5551212",
    "run_number": 842
  },
  "repository": { "full_name": "acme/web-store" },
  "workflow": { "name": "CI" }
}

Example shape written by us, matching GitHub's documented workflow_run event payload; check GitHub's own documentation for the full object (branches, actor, repository detail, and more).

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
repository.full_name + workflow.name (or workflow_run.name) + head_branch + conclusion	incident title	Built from several fields joined together, not read from one.
workflow_run.conclusion	severity	failure or timed_out→P1, action_required→P2, cancelled or stale→P3, success/skipped/neutral→P4; when action is not completed (requested or in_progress), severity is always P4 regardless of any conclusion value present.
workflow_run.html_url, else run_number and status joined	incident body
repository.full_name + workflow name	identity signal	The run id and run number are deliberately excluded, so consecutive failing runs of the same workflow collapse instead of opening a new incident every run.

How CallHeim processes it

Routing

Each alert source is bound to a service, and the service’s escalation policy (or its team’s) sets who is paged.

Deduplication

Repeats of the same alert collapse onto one incident while they keep arriving within five minutes of each other. A repeat that arrives after a longer quiet gap opens a new incident. Identity is the repository and workflow name together — not the run id — so consecutive failures of the same workflow collapse onto one incident even though every run has its own id and run number.

Recovery

GitHub Actions has no recovery event to recognise: a workflow_run notification describes one completed run, not a state that later clears. There is no separate "this workflow is passing again" webhook, so a later successful run does not post anything that tells CallHeim the earlier failure is over. A person resolves the incident once a later run is known to have passed.

Troubleshooting

Common problems and how to fix them
Problem	Fix
No alerts arrive at all.	The webhook is likely still set to the default push event — open the webhook's settings and select "Workflow runs" explicitly under "Let me select individual events."
A run that's still in progress pages.	Expected — CallHeim reads every workflow_run delivery, including requested and in_progress; those are stored at P4 (informational) rather than skipped, so a running workflow does show up, just at low severity.
A cancelled run pages at an unexpectedly high severity, or the reverse.	Confirm the delivery's action is completed and check the actual conclusion value delivered — cancelled or stale map to P3, not P1; only failure and timed_out map to P1.
HTTP 401 once you enabled signing.	Confirm the Secret set on the GitHub webhook is exactly the signing secret CallHeim generated for this integration — GitHub recomputes the signature per delivery, so a mismatched secret fails every request, not just the first.
Repeats from what look like unrelated workflows collapse together.	Shouldn't happen — identity includes the workflow name. Check workflow.name isn't empty in the delivered payload (it falls back to workflow_run.name, then to the literal word "workflow", which two differently-named-but-misconfigured workflows could both hit).

Security

CallHeim verifies an HMAC-SHA256 signature on each source’s requests once you enable signing on that integration (the sending tool must be able to sign). GitHub signs each delivery itself with HMAC-SHA256 over the raw request body, sent as X-Hub-Signature-256: sha256=<hex digest>. That is the exact header and format CallHeim's signature check accepts — paste the signing secret CallHeim generates for this integration into the webhook's Secret field on GitHub's side and turn signing on; unlike most sources in this catalogue, no custom-header workaround is needed. Until you do, the ingest URL itself is the credential.

Vendor documentation checked

GitHub: workflow_run webhook event — checked 2026-09-24
GitHub: Validating webhook deliveries — checked 2026-09-24

The thresholds it passes through

Dedup window: 300s
Flap threshold: 4 transitions / 600s
Title correlation: similarity ≥ 0.6, same source and service
Group window default: 600s

All defaults are published. You can turn title correlation off or change its threshold, and set the window on your own noise rules; the dedup window and the flap settings are fixed. How alerts are processed →

Send GitHub Actions alerts to on-call with CallHeim.