Dash0 acquires Polar Signals

Last updated: August 13, 2026

Set Up GitLab Integration

Connect a GitLab instance to Dash0 so Agent0 can clone repositories and work with merge requests as the person who asked.

Connect GitLab to Dash0 so Agent0 can read source code, propose fixes, and open merge requests during investigations. Both GitLab.com and self-managed instances are supported.

The GitLab integration has two parts, and both are required:

  • The organization connection: An administrator connects Dash0 to a GitLab instance using a group service account and a webhook. This gives Dash0 read access to the groups you list.
  • Your personal connection: Each member connects their own GitLab account. Agent0 uses that grant to act in GitLab as the person who asked, so every clone, push, merge request, and comment is attributed to them and limited to their own GitLab permissions.
Important

There is no shared Dash0 bot account for GitLab. The organization's service account serves system information only and cannot act for a person. If you have not connected your own GitLab account, Agent0 cannot reach GitLab for you.

Tip

To create a GitLab integration, navigate to Settings → Integrations, click + Add, and select GitLab from the integration type list.

Prerequisites

Before setting up the GitLab integration:

  • GitLab 16.1.0 or newer. Dash0 authenticates as a group service account with its own access token, and both arrived in GitLab 16.1.
  • HTTPS. Dash0 sends the access token on every request, so plain HTTP is not accepted.
  • Reachable from Dash0. A self-managed instance must be reachable from Dash0 over the public internet. Air-gapped instances are not supported.
  • Organization administrator role in Dash0.
  • Owner or Maintainer of the top-level GitLab group, so you can create a service account, issue its token, and add group webhooks.

Step 1: Connect Your Organization

A Dash0 organization administrator does this once per GitLab instance.

Create a GitLab Service Account

Dash0 connects as a service account rather than as a person, so the integration keeps working when team members leave.

  1. In your top-level GitLab group, create a service account under Settings → Service accounts.
  2. Give the service account an access token with the read_api scope. GitLab calls this a personal access token even though it belongs to the service account.
  3. Invite the service account to every group you plan to add in Dash0, under that group's Manage → Members.
Important

Creating the service account does not grant it access to anything, and a private group is invisible to a non-member. If you skip the invitation step, Dash0 rejects the connection because it cannot see the group.

Add the Integration in Dash0

  1. Navigate to Settings → Integrations.
  2. Click + Add and select GitLab.
  3. Choose the GitLab instance type:
    • GitLab.com (cloud): No instance URL is needed.
    • Self-managed: Enter the Instance URL of your instance, for example https://gitlab.example.com.
  4. Under Groups, add each group you want to connect:
    • Group ID or path: The Group ID from the group's Settings → General page, or its full path including parent groups.
    • Access token: The service account's personal access token, which starts with glpat-.
  5. For a self-managed instance, complete the OAuth section as described in Register an OAuth Application.
  6. Click Connect.

You can add up to 10 groups to one integration. Each group carries its own access token, because GitLab issues group access tokens per group.

Info

An integration is anchored to a single GitLab instance, and each instance can be connected only once per Dash0 organization. You can connect several instances, such as GitLab.com and gitlab.example.com, as separate integrations.

What Dash0 Verifies at Connect Time

Dash0 calls the GitLab API before saving and refuses the connection if any check fails:

  • Instance version: Read from the instance and rejected if it is below 16.1.0.
  • Token owner: The token must belong to a service account. A token belonging to a human account is refused.
  • Token scopes: The token must carry the read_api scope.
  • Group access: Every group you listed must be reachable with its token.

Verification captures metadata that appears read-only in the Connection section of the integration page: Service account, Instance version, Token scopes, Token expires, and Last verified.

Dash0 verifies again only when you change the instance URL, a group, or an access token. Editing anything else keeps the stored metadata and makes no API call, so the integration stays editable while the instance is unreachable or a token has expired.

Register an OAuth Application (Self-Managed Only)

The OAuth application is what lets individual members connect their own GitLab accounts. GitLab.com uses a Dash0-owned application, so there is nothing to register. Self-managed instances need their own.

  1. In the Dash0 integration's OAuth section, copy the Redirect URI that Dash0 shows.
  2. In GitLab, go to Settings → Applications and create an application with the api scope and that exact redirect URI.
  3. Paste the application's Application ID and Application secret back into Dash0.

Both values are required. Saving a self-managed integration without them is rejected with a field-level error.

Add the Webhook

The webhook is how GitLab notifies Dash0 about activity in a connected group. Each integration has its own webhook URL.

  1. In the Dash0 integration's Webhook section, copy the Webhook URL.
  2. In GitLab, go to the group's Settings → Webhooks and add a webhook with that URL.
  3. Supply the webhook credential. Dash0 shows the field that matches your instance version:
    • GitLab 19.1 or newer: Dash0 shows a Signing token field. In GitLab, select Generate signing token and paste the value into Dash0. GitLab shows it only once.
    • Below GitLab 19.1: Dash0 shows a Secret token field and generates the value itself. Copy it into the webhook's Secret token field in GitLab. Use Generate new token to replace a stored token, since the stored value cannot be shown again.

Repeat this for every group you added, because GitLab generates a distinct signing token per webhook.

Note

The two credentials flow in opposite directions. A signing token is generated in GitLab and pasted into Dash0. A secret token is generated in Dash0 and pasted into GitLab. Signing tokens are the stronger option, because they authenticate the request body and its timestamp rather than presenting a shared password. Dash0 always validates using the credential it has stored, so possessing a weaker credential cannot downgrade a stronger configuration.

Step 2: Connect Your Own GitLab Account

Every member connects their own GitLab account, including members who are not administrators. Until you do, Agent0 cannot act in GitLab for you.

  1. Open the GitLab integration in Settings → Integrations.
  2. In the Your GitLab account card, click Connect GitLab.
  3. Authorize Dash0 in the GitLab window that opens.
  4. The card shows your connected GitLab username when the grant succeeds.

What the Grant Covers

Dash0 requests the api scope, which is GitLab's full user scope. Narrower scopes cannot support the work Agent0 does:

  • read_api cannot write. Commenting on a merge request or opening one is a write.
  • read_repository and write_repository cover Git only. They do not cover the API objects Agent0 reads for context, such as merge requests, issues, and pipelines.

api is the only GitLab scope that spans both. This is a broad grant, which is why it is per person and revocable by that person rather than an organization-wide credential. The grant covers only what you can already do in GitLab, and every action Agent0 takes is attributed to you.

Revoke Your Connection

  • In Dash0: Click Disconnect in the Your GitLab account card.
  • In GitLab: Revoke the authorization under your user settings' applications page. The Dash0 card links directly to the right page on your instance.

An expired or revoked grant appears as a warning in the card with a Reconnect action. Agent0 reports the same state as a warning when you ask it to do GitLab work.

Manage the Integration

View Integration Status

Open the GitLab integration in Settings → Integrations to review the Groups, OAuth, Connection, and Webhook sections, along with your own connection in the Your GitLab account card.

Watch for Token Expiry

GitLab group access tokens expire within 365 days at the latest. Dash0 captures the expiry date and shows it as Token expires in the Connection section. Note the date and issue a replacement token before it lapses, because an expired token stops the integration from reading the group.

Remove the Integration

  1. Open the GitLab integration in Settings → Integrations.
  2. Click Delete Integration and confirm.
  3. Remove the webhook in GitLab.
Important

Deleting the integration deletes the stored access token and webhook credential, but the webhook itself stays in GitLab and keeps sending events. Remove it in the group's Settings → Webhooks as well.

Troubleshooting

Dash0 Rejects the Connection

  • Group not reachable: Confirm the service account was invited to that group under Manage → Members. This is the most common cause.
  • Token belongs to a person: The access token must belong to a service account, not to a human account.
  • Missing scope: The token needs the read_api scope.
  • Instance version too old: Dash0 requires GitLab 16.1.0 or newer.
  • URL rejected: The instance URL must use HTTPS and must resolve to a public address. Dash0 refuses private, loopback, link-local, and cloud metadata addresses.

Agent0 Says You Are Not Connected

Agent0 reports the warning gitlab_user_not_connected when the organization has a GitLab integration but you have not completed Step 2. Connect your GitLab account and ask again.

Agent0 Says the Connection Needs Reconnecting

Agent0 reports the warning gitlab_connection_needs_reconnect when a grant has expired or was revoked in GitLab. The warning names each affected host. Click Reconnect in the Your GitLab account card for that instance.

Agent0 Cannot Reach GitLab at All

Agent0 reports the warning gitlab_network_level_blocks_clis when the thread's network mode cannot reach the GitLab host. See Network Modes for which mode reaches which host.

Agent0 Refuses to Write

Agent0 reports the warning gitlab_clis_readonly_via_mcp when it is invoked through the Dash0 MCP with a read-only action scope. Reads work, and writes are refused before GitLab is contacted. Run the request from Dash0 Chat, Slack, or Linear instead.

404 Project Not Found

Agent0 uses your GitLab token, so it can only see what you can see. A "404 Project Not Found" usually means your GitLab account lacks access to that project rather than that the path was wrong.

Dash0 Does Not Receive Webhook Events

  • Credential mismatch: Confirm the credential in GitLab matches what Dash0 stored. A failed validation is rejected and is not recorded as a delivery.
  • Wrong scope: The webhook has to be registered as a group webhook, on each group you connected, not as a project webhook.
  • Wrong URL: Each integration has its own webhook URL. Copy it from that integration's Webhook section.

Security

  • Service account, not a person: The organization connection uses a GitLab service account with the read-only read_api scope, so it survives team changes and cannot write anything.
  • Per-person attribution: Writes run under the requesting person's own grant. Nothing Agent0 does in GitLab is anonymous, and nothing exceeds that person's GitLab permissions.
  • No bot fallback: If a person has no connection, the operation fails with a message asking them to connect. The service-account token is never substituted.
  • HTTPS enforced: Plain HTTP instance URLs are refused during input validation and again in the API client.
  • Outbound request filtering: Dash0 refuses instance URLs that resolve to private, loopback, link-local, or cloud metadata addresses, both when the integration is saved and before every outbound request.
  • Signed webhooks: On GitLab 19.1 and newer, deliveries are authenticated with an HMAC signature over the request body and timestamp, compared in constant time, with a timestamp tolerance that rejects replays.
  • Deduplicated deliveries: Deliveries are recorded per integration and delivery ID, so a GitLab redelivery is acknowledged without being processed twice.
  • Encrypted secrets: Access tokens, OAuth secrets, webhook credentials, and personal grants are encrypted at rest.
  • Credentials never in arguments: Tokens are passed to git and glab through configuration and environment, never on the command line.

Further Reading