Linking Trigger.dev as a source

Alpha release

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

The Trigger.dev connector syncs your task run history, schedules, and queues into PostHog, so you can analyze background-job execution data alongside your product analytics.

Prerequisites

You need a Trigger.dev project and a secret API key for the environment you want to sync. API keys are per environment (dev, staging, prod), so one connection syncs one environment. Self-hosted Trigger.dev instances are also supported.

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 Trigger.dev, you'll need:

Secret API key – copy the secret key for the environment you want from your Trigger.dev project's API keys page. Keys are prefixed by environment: tr_prod_..., tr_stg_..., or tr_dev_....
API URL (optional) – leave blank for Trigger.dev Cloud. If you self-host, set it to your instance's API URL (must be HTTPS).

Available tables

Table	Description	Sync method
`runs`	A single execution of a task, with status, timings, and cost	Incremental on `createdAt`
`schedules`	Schedules that trigger tasks on recurring cron expressions	Full refresh
`queues`	Task queues with live concurrency and depth counters	Full refresh

Incremental syncs on the runs table use a 3-day lookback window. Runs are created with an immutable createdAt timestamp, but fields like status and costInCents keep updating after creation. The lookback re-reads recently created runs each sync to pick up those late changes. Merge deduplication on the run id prevents duplicates.

Full refresh tables (schedules and queues) reload all data on each sync. These are typically small and have no stable timestamp to sync on.

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

Configuration

Option	Type	Required
`Secret API key`	password	Yes
`API URL (self-hosted only)`	text	No

Supported tables

Table	Description	Sync method	Incremental field	Primary key
`runs`	A single execution of a Trigger.dev task, with its lifecycle status, timings, and cost.	Incremental, Full refresh	createdAt	—
`schedules`	A schedule that triggers a task on a recurring cron expression.	Full refresh	—	—
`queues`	A task queue and its live concurrency and depth counters.	Full refresh	—	—

Troubleshooting

If runs stop syncing with an authorization error, the API key was likely rotated or belongs to a different environment. Generate a fresh secret key for the correct environment and reconnect.
Each API key is scoped to a single environment (dev, staging, or prod). Make sure you're using the key for the environment you want to sync.

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.