Skip to main content
Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more
Use a GitLab project or group webhook to sync deployments to Flashduty On-call. Each deployment becomes one Flashduty change; every state of a deployment, from waiting for approval through running to success, failure or cancellation, updates that same change. GitLab CI/CD jobs that declare an environment create deployments automatically, so projects that release with GitLab CI/CD can connect without changing their pipelines. This works for both GitLab.com and self-managed GitLab.

In Flashduty On-call

  1. In the Flashduty console, go to Integration Center → Change Events
  2. Select GitLab and enter an integration name
  3. To assign changes to specific channels, add rules under the integration’s Routes that match labels such as project or environment
  4. Click Save and copy the generated Push URL

Configure GitLab

1

Open webhook settings

  • Project: go to the project’s Settings → Webhooks and click Add new webhook
  • Group (GitLab Premium or higher): go to the group’s Settings → Webhooks and click Add new webhook; the group sends deployments from every project
Project webhooks need the Maintainer or Owner role on the project; group webhooks need the Owner role on the group.
2

Enter the Push URL

  1. URL: paste the complete Flashduty integration Push URL
  2. Signing token and Secret token: not needed; Flashduty authenticates the request with the integration_key in the Push URL
3

Select events

  1. Under Trigger, select only Deployment events and clear the default Push events
  2. Keep Enable SSL verification selected and click Add webhook
GitLab’s Test feature cannot send deployment events. Other events sent with Test (such as Push events) get a success response from Flashduty but create no change.

How changes are merged

To connect several GitLab instances (for example GitLab.com and a self-managed instance), create one integration per instance; otherwise deployments from different instances can merge into one change.

Status mapping

Done, Failed and Canceled are end states; Flashduty records the change’s end time. GitLab only sends events for blocked, running, success, failed and canceled. These deliveries get a success response but create no change: event types other than Deployment (Push, Pipeline, and so on), and the protected-environment approval events approved and rejected. An approval event describes the approval, not the deployment. After an approval, GitLab sends running when the deployment starts; after a rejection, it sends failed. The change status follows those deployment events.

Change content

Use labels for routing and for filtering the change list:

FAQ

  • Make sure the webhook has Deployment events selected. With only Push events selected, no changes are created
  • Check the deliveries and Flashduty’s responses under Recent events on the GitLab webhook edit page
  • Only GitLab deployments produce deployment events, for example a CI/CD job that declares an environment, or a call to the Deployments API
No. Flashduty records an event with the same status and the same time only once.
After a deployment is rejected, GitLab sends failed; Flashduty sets the deployment status to Failed, with the state label set to failed.
  • … is missing or invalid …: the payload is incomplete or a field is malformed. Confirm it comes from a native GitLab webhook
  • unsupported … or unknown …: Flashduty does not support this deployment status yet. Contact us