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

# Linking Depot as a source

![](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

**Alpha release**

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

The Depot connector syncs the Depot CI job attempts of one GitHub repository into the PostHog Data warehouse, with one row per attempt. You can then query how long your CI jobs take, how often they fail, and how often they are retried.

## Prerequisites

You need a Depot organization that runs Depot CI for the repository, and an organization API token for it.

Each source syncs one repository. To sync another repository, add another Depot source.

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

When linking Depot, you'll need:

-   **API token**: an organization API token. Create one in the **API Tokens** section of your Depot organization settings.
-   **Repository**: the GitHub repository to sync, as `owner/name`, for example `PostHog/posthog`.

PostHog checks both values when you connect by listing the repository's Depot CI runs. If Depot rejects them, the connection fails and shows the reason.

## 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](/docs/cdp/sources.md#sync-methods) for a full explanation of how each mode works and how to choose between them.

`job_attempts` supports incremental, append only, and full refresh syncs. Incremental and append only syncs use `run_created_at`, the time the run was created, as the cursor.

-   The first sync imports runs created in the 7 days before it. Older runs are not imported.
-   PostHog imports a run only after its status is `finished`, `failed`, or `cancelled`.
-   Each sync stops at the oldest run that is still queued or running. Finished runs created after it wait for a later sync. A run that has been queued for more than 6 hours counts as stuck and does not hold the sync back.
-   Incremental and append only syncs read each run once, after it ends. If you re-run a job after PostHog synced its run, the new attempt is not imported. A full refresh reads every run again, so it imports the attempt once the run ends.

## Configuration

| Option | Type | Required |
| --- | --- | --- |
| `API token` | password | Yes |
| `Repository` | text | Yes |

## Supported tables

| Table | Description | Sync method | Incremental field | Primary key |
| --- | --- | --- | --- | --- |
| `job_attempts` | One row per attempt of a Depot CI job, with the context of its run, workflow, and job. Jobs that never ran, such as skipped jobs and matrix expansion placeholders, have no rows. | Incremental, Full refresh | run\_created\_at | — |

Each `job_attempts` row also holds the job, workflow, and run the attempt belongs to, so you can group attempts by workflow or by run without a join. Jobs that never ran, such as skipped jobs and matrix expansion placeholders, have no rows.

## Troubleshooting

-   If you see **Enter the repository as owner/name**, enter only the owner and the repository name separated by a slash, for example `PostHog/posthog`. Do not enter a URL.
-   If you see a **401** error, or **Depot didn't accept this API token**, the token is wrong or no longer valid. Copy the whole token, or create a new organization API token, then reconnect.
-   If you see a **403** error, or **This API token can't read Depot CI runs**, the token can't read Depot CI, for example because it is not an organization API token. Create an organization API token in your Depot organization settings, then reconnect.
-   If you see **Couldn't list Depot CI runs**, Depot returned another error for the repository. Check the repository name and try again.
-   If a recent run is missing, it is still running, or an older run is still queued or running. Its rows appear on the first sync after those runs end.

If your sync is failing or data looks wrong, see the [Data warehouse troubleshooting guide](/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.

### Still have questions?

Ask PostHog AI

### Was this page useful?

HelpfulCould be better