> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Linking Buildkite as a source

Canonical URL: https://posthog.com/docs/data-pipelines/sources/buildkite

> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://us.posthog.com` or `https://app.posthog.com` (app host for links).

## On this page

- [Prerequisites](#prerequisites)
- [Adding a data source](#adding-a-data-source)
- [Sync modes](#sync-modes)
- [Configuration](#configuration)
- [Supported tables](#supported-tables)
- [Troubleshooting](#troubleshooting)

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_9608fcca70)

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_dark_a92b0e022d)

Let AI connect your sources for you

Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.

`npx @posthog/wizard warehouse`

![PostHog Wizard hedgehog](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)

![](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)Let AI connect your sources for you

The Buildkite connector syncs organizations, organization members, pipelines, and more into the PostHog data warehouse, so you can analyze them alongside your product data.

## Prerequisites

Credentials that can read the data you want to sync. PostHog only reads data, so read access is enough.

## Adding a data source

1.  In PostHog, go to the [Sources tab](https://app.posthog.com/data-management/sources) of the data pipeline section.
2.  Click **\+ New source** and click **Link** next to this source.
3.  Enter your credentials (see [Configuration](#configuration) below) and click **Next**.
4.  Select the tables you want to sync, choose a sync method and frequency, then click **Import**.

Once the syncs are complete, you can start querying this data in PostHog.

Enter your Buildkite API access token and organization slug to sync your CI/CD data.

You can create an API access token in your [Buildkite account settings](https://buildkite.com/user/api-access-tokens).

Make sure to grant the following read scopes:

-   `read_organizations`
-   `read_pipelines`
-   `read_builds`
-   `read_agents`
-   `read_clusters`
-   `read_teams`
-   `read_suites`

You'll be asked for:

-   **API access token**: for example `bkua_...`.
-   **Organization slug**: for example `my-organization`.

## Sync modes

Each table can be synced in one of several modes, depending on what the source supports:

-   **Webhook** (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
-   **Incremental** – only new or updated rows are synced on each run, using a cursor field (such as an `updated_at` timestamp). Cheaper than a full refresh, but deletes aren't captured.
-   **Append only** – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
-   **Full refresh** – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.

See [sync methods](https://posthog.com/docs/data-pipelines/sources.md#sync-methods) for a full explanation of how each mode works and how to choose between them.

All Buildkite tables are full refresh. Each sync replaces the contents of the table.

## Configuration

| Option | Type | Required |
| --- | --- | --- |
| `API access token` | password | Yes |
| `Organization slug` | text | Yes |

## Supported tables

| Table | Description | Sync method | Incremental field | Primary key |
| --- | --- | --- | --- | --- |
| `organizations` | A Buildkite organization the API access token can read. | Full refresh | — | — |
| `organization_members` | A user who belongs to the organization, resolving the user ids carried on builds, teams, and schedules. | Full refresh | — | — |
| `pipelines` | A pipeline defines the steps Buildkite runs for a project's builds. | Full refresh | — | — |
| `pipeline_schedules` | A cron schedule that creates builds for a pipeline, which distinguishes scheduled builds from triggered ones. | Full refresh | — | — |
| `builds` | A single run of a pipeline, made up of one or more jobs. | Incremental, Full refresh | created\_at | — |
| `jobs` | Fetches the jobs of every build, at least one request per build. Disabled by default because of the API cost | Incremental, Full refresh | build\_created\_at | — |
| `artifacts` | Fetches the artifacts of every build, at least one request per build. Disabled by default because of the API cost | Incremental, Full refresh | build\_created\_at | — |
| `annotations` | Fetches the annotations of every build, at least one request per build. Disabled by default because of the API cost | Incremental, Full refresh | build\_created\_at | — |
| `agents` | A connected Buildkite agent that runs jobs for the organization. | Full refresh | — | — |
| `clusters` | An isolated group of agents, queues and pipelines within the organization. | Full refresh | — | — |
| `cluster_queues` | A queue within a cluster, resolving the queue an agent or job ran on for capacity and cost analysis. | Full refresh | — | — |
| `teams` | A team within the organization, used to grant access to pipelines and suites. | Full refresh | — | — |
| `team_pipelines` | A link between a team and a pipeline, with the access level the team's users hold. Use it to attribute pipelines and build cost to teams. | Full refresh | — | — |
| `team_members` | A link between a team and a user, with the role the user holds in the team. | Full refresh | — | — |
| `test_suites` | A Test Engine suite collecting the test results uploaded for a project. | Full refresh | — | — |
| `test_suite_runs` | One upload of test results to a Test Engine suite, usually one per CI build. | Full refresh | — | — |
| `test_suite_tests` | An individual test tracked by a Test Engine suite, with the labels applied to it. | Full refresh | — | — |

## Troubleshooting

-   If the connection fails with an authorization error, the API access token is wrong, expired, or has been revoked. Create a new one, then reconnect the source.
-   If a table syncs no rows, the credential may not have access to that data. Check its permissions, then reconnect the source.

If your sync is failing or data looks wrong, see the [Data warehouse troubleshooting guide](https://posthog.com/docs/data-warehouse/troubleshooting.md). If that doesn't help, [contact support](https://us.posthog.com/#panel=support%3Asupport%3Adata_warehouse%3A%3Atrue) – we're happy to help.