Skip to main content
Use a GitLab project or group webhook to sync failed pipelines, failed deployments and security vulnerabilities to Flashduty On-call. Each branch or tag, each environment and each vulnerability maps to one Flashduty alert: a branch’s alert triggers when its pipeline fails and recovers when a later pipeline on that branch succeeds; an environment’s alert triggers when a deployment fails and recovers when a later deployment succeeds; a vulnerability’s alert triggers when it is detected and recovers when it is resolved or dismissed.

​
In Flashduty On-call

You can obtain an integration push URL in either of the following ways.

​
Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select GitLab, then click Save
  4. Open the generated integration card and copy the Push URL

​
Use a shared integration

  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select GitLab and enter an integration name
  3. Configure the default route and select a channel; after creation, add more rules under Route if needed
  4. Click Save and copy the generated Push URL

​
Configure GitLab

GitLab.com, GitLab Self-Managed and GitLab Dedicated all support webhooks. Project webhooks are available on every tier and require the Maintainer or Owner role on the project. Group webhooks require Premium or Ultimate and the Owner role on the group, and send events from every project in the group and its subgroups.
1

Add a webhook

  1. In GitLab, open the project (or group) to connect, then select Settings → Webhooks in the left sidebar
  2. Click Add new webhook
  3. Paste the full Flashduty push URL into URL. The URL must include integration_key
  4. Leave Signing token and Secret token empty. Flashduty authenticates the request with the integration_key in the URL
  5. Leave Custom webhook template empty. Flashduty parses GitLab’s default request body
2

Select the events

Under Trigger, select the following events. Other events are not needed; if selected, Flashduty acknowledges them and creates no alert:Vulnerability events require GitLab 17.11 or later (on 17.7 to 17.10, an administrator must turn on the vulnerabilities_as_webhook_events feature flag). Vulnerability records in a project require GitLab Ultimate.
3

Save and verify

  1. Keep Enable SSL verification selected and click Add webhook
  2. In the webhook list, click Test and select Pipeline events. GitLab sends the real data of the project’s latest pipeline: if that pipeline failed, Flashduty creates an alert for its branch; if it succeeded, no new alert appears
  3. Make a pipeline fail on a branch (for example, commit a failing test) and confirm that Flashduty receives an active alert. After fixing it, run a successful pipeline on the same branch and confirm that the alert recovers
For Push events (the default Test option) and other events unrelated to this integration, Flashduty returns success and creates no alert. GitLab cannot send a deployment event from Test. Testing Vulnerability events sends a real vulnerability from the project; if it needs triage or is confirmed, Flashduty creates its alert.

​
Alert Key

Flashduty builds the Alert Key from the business object, so the trigger and recovery events of one object share one Alert Key: The Alert Key combines the object type with the fields above, so a branch never merges with a tag or an environment of the same name. Renaming or moving the project does not change the Alert Key. A failed or successful event missing these fields is rejected.

​
Status and severity

​
When alerts do not recover automatically

These objects never receive a later successful event, so their alerts do not recover automatically:
  • The branch is deleted or merged after its pipeline failed, or the failed pipeline ran for a tag
  • The failed deployment targeted a temporary environment (such as a Review App review/* environment) that was stopped afterwards
  • An older pipeline on a branch finishes and fails after a newer pipeline on the same branch has succeeded
Turn on the channel’s auto-resolve timeout, set Window timing start to Incident trigger, and set the timeout to 24 hours. Pipeline and deployment failures are usually fixed within a working day. Vulnerability alerts recover when the vulnerability is resolved or dismissed, so a channel that only receives vulnerability alerts can leave the timeout off.

​
Labels

Pipeline variables (variables) and user emails never become labels.

​
Troubleshooting

  • The webhook shows Temporarily disabled or Disabled: GitLab temporarily disables a webhook after 4 consecutive failed deliveries and permanently disables it after 40. Check that the push URL is complete and includes integration_key, then click Test to send a test request and re-enable the webhook
  • A rejected deployment raised an alert: when a deployment to a protected environment is rejected, GitLab sends rejected and then, after dropping the deployment job, failed for the same deployment. Flashduty treats it as a failed deployment; close the alert by hand or let the next successful deployment recover it
  • Merge request pipelines merge into the branch alert: the ref of a merge request pipeline is its source branch, so it shares the Alert Key of that branch’s other pipelines
  • No vulnerability events arrive: check that the GitLab version and the Ultimate subscription meet the requirements and that security scanning is enabled for the project
  • Inspect deliveries: the Recent events tab on the webhook edit page shows the request body of each delivery and the response from Flashduty
For field details, see GitLab webhook events.