
Buildkite
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.

Connect Buildkite to PostHog to sync your data into the PostHog data warehouse for analysis and modeling.
Enter your Buildkite API access token and organization slug to sync your CI/CD data into the PostHog Data warehouse.
You can create an API access token in your Buildkite account settings.
Make sure to grant the following read scopes:
read_organizationsread_pipelinesread_buildsread_agentsread_clustersread_teamsread_suites
Configuration
| Option | Type | Required |
|---|---|---|
API access token | password | Yes |
Organization slug | text | Yes |
Linking Buildkite to PostHog
- Go to the Data pipeline page in PostHog
- Click New source and select Buildkite
- Fill in the required configuration fields
- Click Next, select the tables you want to sync, and then press Import
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 | — |
agents | A connected Buildkite agent that runs jobs for 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 | — | — |
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 | — | — |