Linking JetBrains TeamCity as a source

Alpha release

This source is currently in alpha. The interface and available tables may change.

The JetBrains TeamCity connector syncs your CI/CD data - builds, test results, build problems, VCS changes, projects, and agents - into the PostHog Data warehouse, so you can analyze build duration, pass rates, and deployment frequency alongside your product data.

Prerequisites

You need a TeamCity server (self-hosted or TeamCity Cloud) that PostHog can reach over HTTPS, and a user account with view permissions on the projects and builds you want to sync. The connector reads data through TeamCity's REST API using an access token, which inherits the token owner's permissions.

Adding a data source

In PostHog, go to the Sources tab of the data pipeline section.
Click + New source and click Link next to this source.
Enter your credentials (see Configuration below) and click Next.
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.

When linking TeamCity, you'll need:

Server URL – the root URL of your TeamCity server, for example https://teamcity.example.com. If your server runs under a context path, include it, for example https://ci.example.com/teamcity.
Access token – create one in TeamCity under Your profile → Access Tokens.

Sync modes

The builds and changes tables support incremental syncs: only builds finished (or changes committed) after the last sync are fetched. The test_occurrences and problem_occurrences tables are fetched per build, so their incremental syncs only cover newly finished builds. Because a first sync of these two tables walks your server's whole retained build history one build at a time, they are not selected by default - enable them deliberately if you want per-test and per-problem history.

Synced builds cover all branches, not just the default branch, and only include finished builds (running, canceled, and personal builds are excluded).

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 for a full explanation of how each mode works and how to choose between them.

Configuration

Option	Type	Required
`Server URL`	text	Yes
`Access token`	password	Yes

Supported tables

Table	Description	Sync method	Incremental field	Primary key
`projects`	A TeamCity project: a container that groups build configurations and child projects.	Full refresh	—	—
`build_types`	A build configuration: the definition of how a build runs (steps, triggers, VCS roots) inside a project.	Full refresh	—	—
`agents`	A build agent: a machine registered with the TeamCity server that runs builds.	Full refresh	—	—
`vcs_roots`	A VCS root: a version control repository connection builds check out sources from.	Full refresh	—	—
`builds`	A finished build: one execution of a build configuration, with queue/start/finish times, status, branch, and agent.	Incremental, Full refresh	finishDate	—
`changes`	A VCS change (commit) detected by the TeamCity server across its VCS roots.	Incremental, Full refresh	id	—
`test_occurrences`	A single test run within a build. One row per test per build, so pass rates and flakiness can be computed over time.	Incremental, Full refresh	build finish date	—
`problem_occurrences`	A build problem within a build (compilation error, exit code failure, etc.). One row per problem per build.	Incremental, Full refresh	build finish date	—

Troubleshooting

If you see an authentication error, your access token is invalid or has expired. Create a new token under Your profile → Access Tokens, then reconnect.
If you see a permissions error, the token owner is missing view permissions on some projects. TeamCity only returns data the token owner can see, so grant the right project permissions, then reconnect.
If some projects or builds are missing, check the token owner's roles - the connector can only sync what that user can view in the TeamCity UI.

If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.