GitHub opens a war room
Once your organization is connected (see Connecting GitHub), GitHub can open a Landfall incident directly from four event types — no separate setup per repository, and no webhook for you to create: it rides the same platform-level App from the connection step.
Every other Landfall trigger integration (PagerDuty, Datadog, Coralogix, CloudWatch) asks you to create your own webhook subscription. GitHub is different: the Landfalls Incident Response App has exactly one webhook URL and one signing secret, configured once by Landfall itself. There is nothing for you to set up here beyond connecting the App — the moment it's installed, its events reach Landfall.
Which events open an incident
| GitHub event | In Landfall |
|---|---|
| code_scanning_alert | Opens an incident when a new or reopened alert meets your severity floor (default: critical/high). Severity comes straight from the alert's own rule severity. |
| secret_scanning_alert | Opens an incident on a new or reopened alert. The secret's type, the repository, and a link to the alert are kept; the leaked value's exact location/fragment is stripped before the event ever lands on a timeline every room participant can read. |
| dependabot_alert | Opens an incident when a new or reopened advisory meets your severity floor, using the advisory's own severity rating. |
| workflow_run | Opens an incident on a failed run of a workflow you've marked deploy-critical (below) — not on every failed run in the repository. |
| installation.deleted / installation_repositories.removed | Never opens an incident. Transitions the connection to disconnected and drops any cached access token immediately, rather than waiting for the next scheduled health check to notice. |
| Everything else | Acknowledged and dropped. GitHub sends many event types this App doesn't act on; each still gets a 200 so GitHub never retries it as a failed delivery. |
The deploy-critical-workflow opt-in
A failed GitHub Actions run is common and usually not incident-worthy on its own — a flaky test, a lint failure on a draft PR. Rather than trigger on every workflow failure across every repository, Landfall only reacts to a run that you've explicitly named as deploy-critical: an (owner, repo, workflow file) triple, set alongside your service→repository mapping in Settings → Integrations → GitHub. A workflow not on that list can fail as often as it likes without opening a war room.
Redeliveries don't create duplicate incidents
Every routed delivery is stamped with GitHub's own delivery id and the alert or run id it carries. Before creating anything, Landfall checks whether an incident already exists for that exact identifier — a delivery GitHub retries (its own reliability mechanism, not something you configure) is acknowledged and ignored the second time, never a second incident.
Every delivery is verified
Every delivery is checked against the App's signing secret before anything else runs. Two different rejections — a bad signature and a signature that's valid but names an installation that isn't connected to any Landfall organization anymore — get the exact same refusal. Nothing distinguishes them from the outside, matching the same anti-enumeration principle Landfall's other trigger webhooks (PagerDuty, Opsgenie) use, so the endpoint can never be used to probe which organizations are connected.
Still strictly read-only
None of this involves Landfall writing back to GitHub. The webhook only receives what GitHub already pushed — it never polls, never acknowledges or dismisses an alert on GitHub's side, and never comments on a run or a PR. Turning on triggering does not change what the App can do; the App's permissions were already read-only from the moment it was installed (see the full permission set).
How this fits the platform
GitHub's incident-triggering model is the same shared pipeline every other trigger source uses — signature verification, normalization, entity/severity resolution, externalRef dedup — with only the event-specific mapping above being GitHub's own. See Integrations Architecture for the full shared model.