Linking Octopus Deploy as a source
This source is currently in alpha. The interface and available tables may change.
The Octopus Deploy connector syncs your deployment data – deployments, releases, projects, environments, tasks, and audit events – into PostHog. This is useful for analyzing deployment frequency, change failure rate, and recovery time per project and environment.
Prerequisites
You need an Octopus Deploy account (Octopus Cloud or self-hosted) and an API key. Self-hosted servers must be reachable from the internet over HTTPS. The API key inherits your user's permissions, so its user needs read access to the spaces you want to sync.
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 Octopus Deploy, you'll need:
- Octopus Deploy URL – your Octopus Cloud URL (like
https://your-org.octopus.app) or your self-hosted server's public URL. - API key – created in the Octopus web portal under your profile > My API Keys. Click New API key, give it a purpose, and copy the generated key (it starts with
API-).
The connector discovers every space your API key can see and syncs each space-scoped table (projects, deployments, releases, and so on) across all of them, with a SpaceId column identifying the space each row belongs to.
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_attimestamp). 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.
Tasks and audit events support incremental syncs. Incremental task syncs filter on completion date, so a task only appears once it finishes. Deployments and releases don't expose a server-side date filter in the Octopus API, so they always sync with a full refresh.
Configuration
| Option | Type | Required |
|---|---|---|
Octopus Deploy URL | text | Yes |
API key | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
spaces | Spaces partition an Octopus Deploy instance; every other resource belongs to exactly one space. | Full refresh | — | — |
projects | A project is a deployable application or component, holding its deployment process, variables, and releases. | Full refresh | — | — |
project_groups | Project groups organize related projects within a space. | Full refresh | — | — |
environments | Environments are the stages deployments are promoted through, such as Development, Test, and Production. | Full refresh | — | — |
channels | Channels let a project run multiple release cadences (for example default and hotfix) with their own version rules and lifecycles. | Full refresh | — | — |
tenants | Tenants model per-customer or per-region deployments of the same project (multi-tenancy). | Full refresh | — | — |
machines | Machines are deployment targets (VMs, Kubernetes clusters, cloud targets) that deployments run against. | Full refresh | — | — |
releases | A release is a versioned snapshot of a project's deployment process, variables, and packages, ready to be deployed. | Full refresh | — | — |
deployments | A deployment is one execution of a release into an environment (optionally for a tenant) — the core record for deployment frequency and DORA metrics. | Full refresh | — | — |
tasks | Incremental syncs filter on completion date, so tasks only appear once they finish | Incremental, Full refresh | CompletedTime | — |
events | Audit events record every significant action on the instance (deployments queued, releases created, settings changed). | Incremental, Full refresh | Occurred | — |
Troubleshooting
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.