- Security alerts: Dependabot alerts, code scanning alerts, and secret scanning alerts. Each GitHub security alert maps to one Flashduty alert, which recovers when the alert is fixed, dismissed, or closed in GitHub.
- Failed Actions workflows: each workflow on each branch maps to one alert. It triggers when a run concludes with
failure,timed_out, orstartup_failure, and recovers when a later run of that workflow on the same branch succeeds.
In Flashduty On-call
You can obtain an integration push URL in either of the following ways.
Use a dedicated integration
- In the Flashduty console, select Channel and open a channel
- Select Configuration → Integrations → Private integration, then click Add an integration
- Select GitHub, then click Save
- Open the generated integration card and copy the Push URL
Use a shared integration
- In the Flashduty console, select Integration Center → Alert Events
- Select GitHub and enter an integration name
- Configure the default route and select a channel; after creation, add more rules under Route if needed
- Click Save and copy the generated Push URL
Configure GitHub
A webhook can be created on a single repository or on an organization (covering every repository in it). A repository webhook requires admin access to the repository; an organization webhook requires the organization owner role.
1
Make sure the security features are on
Security alerts are only raised when the matching feature is enabled. Check under the repository’s Settings → Advanced Security:
Skip this step if you only want Actions failures.
2
Add the webhook
- Repository webhook: open the repository and click Settings → Webhooks → Add webhook. Organization webhook: open the organization and click Settings → Webhooks → Add webhook
- Payload URL: paste the full Flashduty push URL, including
integration_key - Content type: select
application/json(application/x-www-form-urlencodedis also accepted) - Secret: leave it empty. Flashduty identifies the integration by the
integration_keyin the push URL and does not verify signatures - SSL verification: keep Enable SSL verification
- Which events would you like to trigger this webhook?: select Let me select individual events, clear the preselected Pushes, and select the events you need:
- Dependabot alerts
- Code scanning alerts
- Secret scanning alerts
- Workflow runs
- Keep Active selected and click Add webhook
3
Verify connectivity and the lifecycle
GitHub sends a
ping event as soon as the webhook is added. Check under the webhook’s Recent Deliveries that the response code is 200. The ping only verifies that the URL is reachable and does not create an alert.- Actions failure: run a workflow that fails (for example, a
workflow_dispatchworkflow that runsexit 1) and confirm that Flashduty receives an alert. Then make the workflow pass on the same branch and confirm that the alert recovers. - Security alert: add a dependency version with a known vulnerability to a test repository. When Dependabot raises the alert, Flashduty triggers an alert; Dismiss the alert in GitHub and confirm that the Flashduty alert recovers.
Events and alert status
GitHub puts the event type in the
X-GitHub-Event request header and the action in the action field of the body. Flashduty handles them as follows:
ping and other event types (such as a push selected by mistake) also get a success response without creating an alert.
Alert Key
- Security alerts: the Alert Key is built from the event type, the repository ID (
repository.id), and the alert number (alert.number). The alert number is unique per repository and alert type, and GitHub uses it to address the alert in its API (for example,/repos/{owner}/{repo}/dependabot/alerts/{alert_number}). The Alert Key stays the same from creation through fix, dismissal, and reopening, and renaming the repository does not change it. - Actions failures: the Alert Key is built from the repository ID, the workflow ID (
workflow_run.workflow_id), the ID of the repository the run came from (workflow_run.head_repository.id), and the branch (workflow_run.head_branch). Later runs of the same workflow on the same branch, including Re-run, merge into this alert, and any successful run recovers it. Each branch and each workflow gets its own alert; a pull request from a fork never merges with a branch of the same name in your repository. A run without branch information gets its own alert keyed by the run ID (workflow_run.id), which recovers only when a Re-run of that run succeeds.
repository.id, alert.number, workflow_run.id, or workflow_run.workflow_id are rejected.
When alerts do not recover
In these cases no successful run follows, so the alert does not recover on its own:
- The branch was deleted or merged after the failure (for example, a pull request branch), or the workflow no longer runs on that branch
- The failed run has no branch information and was not re-run
- An older run on the same branch finished with a failure after a newer run succeeded
Severity
A recovery event keeps the alert’s existing severity.
Labels
Troubleshooting
- Recent Deliveries shows a failure: open the delivery’s Response. If it is not
200, make sure the push URL is complete and includesintegration_key. GitHub waits at most 10 seconds for a response - Ping succeeds but no alert arrives: make sure the four events above are selected and the repository has the matching security features enabled. Cancelled or skipped workflow runs never create alerts, and a successful run only recovers an existing one
- A security alert does not recover: make sure the alert was fixed, dismissed, or closed in GitHub, and find the matching
fixed,dismissed,closed_by_user, orresolveddelivery in Recent Deliveries - An Actions failure alert never closes: make sure a later run of that workflow succeeded on the same branch. For deleted branches and similar cases, see “When alerts do not recover” above