Zenduty
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 Zenduty to PostHog to sync your data into the PostHog data warehouse for analysis and modeling.
Enter your Zenduty API key to automatically pull your Zenduty incident-management and on-call data into the PostHog Data warehouse.
Create an API key in your Zenduty account under Account Settings → Access → API Keys (account owners and admins only). The key is account-scoped and read access is enough for syncing.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Linking Zenduty to PostHog
- Go to the Data pipeline page in PostHog
- Click New source and select Zenduty
- 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 |
|---|---|---|---|---|
teams | Teams in your Zenduty account. Each team owns its own services, escalation policies, schedules, and members. | Full refresh | — | — |
account_members | Members (users) of your Zenduty account, with their contact details and account role. | Full refresh | — | — |
incidents | Incidents across your Zenduty account, with their status, urgency, and timing — the basis for MTTR/MTTA and incident-volume analysis. | Full refresh | — | — |
services | Services within a team. Each service maps to an escalation policy that dictates how its incidents escalate. | Full refresh | — | — |
escalation_policies | Escalation policies for a team — the ordered rules (schedules and users) that decide who is notified as an incident escalates. | Full refresh | — | — |
schedules | On-call schedules for a team, defining rotations and who is on call at a given time. | Full refresh | — | — |
team_members | Membership rows linking users to a team, including their role within that team. | Full refresh | — | — |
roles | Incident roles defined for a team (e.g. incident commander, communications lead). | Full refresh | — | — |
postmortems | Post-incident retrospectives (postmortems) authored for a team's incidents. | Full refresh | — | — |
maintenance_windows | Scheduled maintenance windows for a team, during which alerting for affected services is suppressed. | Full refresh | — | — |
slas | Service-level agreements configured for a team, used to track response and resolution targets. | Full refresh | — | — |
tags | Tags defined for a team, used to categorize incidents and services. | Full refresh | — | — |