SigNoz Cloud - This page is relevant for SigNoz Cloud editions.
Self-Host - This page is relevant for self-hosted SigNoz editions.

GitLab Pipeline Traces

Overview

Collect GitLab CI/CD pipeline traces using the GitLab Receiver and send them to SigNoz.

The GitLab Receiver is alpha stability. Config schema may change in future releases. The receiver supports traces only.

Each GitLab pipeline event triggers a webhook to the OTel Collector. The receiver converts the completed pipeline and its jobs into a trace with job-level child spans.

Prerequisites

Setup

Step 1. Configure the GitLab Receiver

If you have a collector running, append the gitlab receiver, resource/gitlab processor, and traces pipeline to your existing config.yaml. Otherwise, create a new config.yaml with the full config below.

The collector listens on port 19418 for pipeline webhooks, stamps every trace with service.name, and exports to SigNoz over OTLP.

config.yaml
receivers:
  gitlab:
    webhook:
      # Binds on all interfaces so the collector is reachable externally.
      endpoint: 0.0.0.0:19418
      path: /events
      health_path: /health
      secret: ${env:GITLAB_WEBHOOK_SECRET}

processors:
  resource/gitlab:
    attributes:
      - key: service.name
        value: <service-name>
        action: upsert

exporters:
  otlp:
    endpoint: "ingest.<region>.signoz.cloud:443"
    headers:
      signoz-ingestion-key: ${env:SIGNOZ_INGESTION_KEY}
    tls:
      insecure: false

service:
  pipelines:
    traces:
      receivers: [gitlab]
      processors: [resource/gitlab]
      exporters: [otlp]

Replace the in-file placeholders (edit these directly in the config):

  • <service-name>: A name to identify this pipeline source in SigNoz (e.g. gitlab-ci).
  • <region>: Your SigNoz Cloud region.

Set these as environment variables (${env:...} resolves them at runtime):

  • GITLAB_WEBHOOK_SECRET: A secret string you choose. The receiver checks the X-Gitlab-Token header on every request and rejects any that do not match. If omitted, no secret validation occurs.
  • SIGNOZ_INGESTION_KEY: Your SigNoz Cloud Ingestion Key.

Step 2. Run the OTel Collector

# Set environment variables and start the collector
export GITLAB_WEBHOOK_SECRET=<your-webhook-secret>
export SIGNOZ_INGESTION_KEY=<your-ingestion-key>
./otelcol-contrib --config ./config.yaml

Step 3. Create a GitLab webhook

In your GitLab project, go to Settings → Webhooks and add a webhook:

  • URL: https://<collector-host>:19418/events — the hostname or IP where your OTel Collector is reachable from GitLab. If port-forwarding on Kubernetes, use localhost.

Use HTTPS in production. GitLab sends the secret token in plain text over HTTP. Anyone who intercepts the request can spoof pipeline events.

  • Secret token: The same value you set for GITLAB_WEBHOOK_SECRET.
  • Trigger: Enable Pipeline events only.

Click Add webhook. Use Test → Pipeline events to confirm the collector receives the request.

Validate

Trigger a pipeline run in GitLab. Once the pipeline completes, open the Traces tab in SigNoz. Each pipeline appears as a root span with its jobs as child spans.

Traces appear only after a pipeline completes (success, failed, canceled, or skipped). The receiver needs finished_at to generate trace IDs, so in-progress pipelines return HTTP 204 without producing a trace.

Click a Trace ID to open the span detail view and inspect per-job durations and statuses.

GitLab Pipeline - Sample Traces
GitLab Pipeline - Sample Traces
GitLab Pipeline - Sample Trace Details
GitLab Pipeline - Sample Trace Details

Troubleshooting

Webhook returns 400 Bad Request

Symptom: GitLab reports a failed webhook delivery with HTTP 400.

Likely causes:

  • Secret mismatch: the secret in config.yaml does not match the Secret token in GitLab webhook settings. Verify both values are identical.
  • Wrong event type: the receiver only processes Pipeline Hook events. Other event types (including Job Hook) are rejected. Ensure only Pipeline events is enabled.
  • Missing required headers: if you configured required_headers, every request must include those headers with matching values.

Fix: Correct the mismatched value and re-test with Test → Pipeline events in GitLab.

Traces do not appear in SigNoz

Symptom: The webhook succeeds (HTTP 200 or 204) but no traces show up in SigNoz.

Likely causes:

  • Pipeline still running: the receiver skips in-progress pipelines and returns HTTP 204. Wait for completion.
  • Exporter misconfiguration: verify endpoint and signoz-ingestion-key are correct. Check collector logs for export errors.
  • Network or firewall: ensure the collector can reach ingest.<region>.signoz.cloud:443.

Fix: Check collector logs (docker logs <container> or kubectl logs) for errors. Trigger a new pipeline and confirm completion before checking SigNoz.

Webhook delivery fails in GitLab

Symptom: GitLab cannot reach the webhook URL at all (connection timeout or refused).

Likely causes:

  • Collector not running: verify the collector process is up and listening on the configured port.
  • Firewall or network: the collector must be reachable from GitLab. For self-managed GitLab, check network policies. For GitLab.com SaaS, the collector must be publicly accessible or tunneled.
  • Wrong URL: verify the URL includes the correct host, port (19418), and path (/events).

Fix: Test connectivity with curl https://<collector-host>:19418/health — a healthy collector returns {"text": "GitLab receiver webhook is healthy"}.

Limitations

  • Traces only: no metrics or logs.
  • Pipeline events only: the receiver processes Pipeline Hook webhooks only. Other event types (including Job Hook) are not processed and return an error.
  • No child or multi-project pipelines: parent-child pipeline relationships are not preserved; each pipeline produces a separate independent trace.
  • No manual instrumentation correlation: trace IDs are a SHA-256 hash of the pipeline ID and finished_at timestamp, available only after completion. Application-level spans cannot be correlated with pipeline spans.
  • Alpha stability: receiver is in alpha. Config schema may change in future otelcol-contrib releases.

Next Steps

Get Help

If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack.

If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.

Last updated: April 26, 2026

Edit on GitHub

Was this page helpful?

Your response helps us improve this page.