GitLab Webhooks: Send Pipeline and Push Events to Sazabi

Webhook facts checked on the platform’s docs on Nov 8, 2026.

A GitLab webhook sends a request to a URL when something happens in a project or group: a push, a merge request, a pipeline finishing. This page covers what the request contains and how to store it in Sazabi.

What GitLab sends

GitLab documents a list of event types that can trigger a webhook. Common ones are push events, tag push events, merge request events, pipeline events, job events, deployment events, release events and comment events. Group webhooks add group member, project and subgroup events.

Each request is JSON. The first field of every example in the docs is object_kind, such as push, tag_push or pipeline. The event name also arrives in the X-Gitlab-Event header, for example Pipeline Hook.

Two limits shape what you receive. A push that touches more than three branches or tags by default triggers no webhooks at all. And an author with no public email listed in their profile gets a redacted value in the email attribute.

Why send it to Sazabi

Pipeline and deployment events are the part of your delivery history that explains a change in behavior. Sazabi's Webhook Events source stores each JSON payload as a searchable log record, with the payload under webhook.* attributes. A failed pipeline for a branch and an error that starts at the same time sit in the same place.

A path suffix keeps streams separate. If you add /gitlab to the intake URL, Sazabi stores it as webhook.path. You can create several GitLab webhooks with different suffixes, for example /gitlab/pipelines and /gitlab/merge-requests.

Set it up in GitLab

You need the Maintainer or Owner role for a project, or Owner for a group.

1. Open your project or group and select Settings, then Webhooks.
2. Select Add new webhook.
3. In URL, paste your Sazabi intake URL with a suffix. Percent-encode special characters.
4. Optionally select Generate signing token and keep a copy. GitLab then signs each request in the webhook-signature header. Leave the secret token empty: GitLab sends it as plain text.
5. Under Trigger, tick the events you want.
6. Leave Enable SSL verification on, and select Add webhook.

To test, use the Test option for the webhook and pick an event type. To test push events, the project needs at least one commit. Run a pipeline or open a merge request to see a real delivery.

Example payload

An abbreviated pipeline event, with field names from the GitLab docs. It is an example, not a captured delivery.

{
  "object_kind": "pipeline",
  "object_attributes": {
    "id": 31,
    "ref": "master",
    "status": "failed",
    "detailed_status": "failed",
    "created_at": "2016-08-12T15:23:28.000Z",
    "duration": 63
  },
  "user": { "username": "root" },
  "project": { "name": "Gitlab Test", "path_with_namespace": "gitlab-org/gitlab-test" }
}

In a Sazabi thread, search for webhook.object_kind to separate event kinds. Add a project name from the payload to follow one repository.

What to watch for

• Automatic disabling. Slow, unstable or misconfigured receivers might be disabled automatically. GitLab treats a 4xx or 5xx response, a timeout and other HTTP errors as failures. Disabled webhooks show a Temporarily disabled or Disabled badge in the webhook list.
• Silent stops. After 40 consecutive failures a webhook stays disabled until you send a successful test request. A flat line in event volume is the first sign.
• Duplicates. The docs say to prepare for duplicate events if a webhook times out. The webhook-id header stays the same across retries, but it is a header, so use body fields such as the pipeline id and status to spot repeats.
• Push limit. Pushing many branches at once can produce no event at all.
• Recent events. GitLab keeps two days of requests per webhook. Use them to see the status code Sazabi's endpoint returned.

The Intake page in the Sazabi dashboard shows ingestion volume per source. Compare it with the pipeline runs you expect.

Retries and signing

GitLab's documentation describes disabling rather than a fixed redelivery schedule. A webhook that fails four consecutive times is temporarily disabled, first for one minute, with the time growing on later failures up to 24 hours. At 40 consecutive failures it is disabled until you test it. You can also resend a request from Recent events.

GitLab can sign requests with a signing token, in the Standard Webhooks format. The older secret token is a plain value, not a signature. Teams that track tickets next to code can send Jira events the same way, and Webflow covers site publish events.