Linking Splunk Observability Cloud as a source
This source is currently in alpha. The interface and available tables may change.
The Splunk Observability Cloud connector syncs your monitoring data – detectors, alert events, incidents, dashboards, charts, teams, and metric metadata – into PostHog, so you can keep alert history beyond the platform's retention and join it with your product data.
Prerequisites
You need a Splunk Observability Cloud (formerly SignalFx) account and an access token with API permission. An org access token or a user session token both work; the token needs the admin, power, or read_only role to read detectors and their events.
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 Splunk Observability Cloud, you'll need:
- Realm – the short code for the region your organization runs in, like
us0oreu0. It's shown on your profile page in Splunk Observability Cloud. - Access token – create one under Settings > Access tokens with API permission. Note that org access tokens expire after a year and session tokens after 30 days, so you'll need to rotate the token before it expires.
- SignalFlow program (optional) – only needed if you want to sync the
metric_time_seriestable. The program's published output is pulled incrementally by time window, for exampledata('cpu.utilization').mean().publish().
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.
Detector events and metric time series sync incrementally on their timestamp. The other tables are configuration and metadata objects, which sync as a full refresh.
Configuration
| Option | Type | Required |
|---|---|---|
Realm | text | Yes |
Access token | password | Yes |
SignalFlow program (optional, for metric_time_series) | textarea | No |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
detectors | Detectors that monitor signals and trigger alert events when their conditions are met. | Full refresh | — | — |
detector_events | Alert events generated by every detector. The API returns at most 10,000 events per detector, so older history beyond that cap is not synced | Incremental, Full refresh | timestamp | — |
incidents | Incidents opened by detectors, grouping the trigger and clear events of one anomaly. | Full refresh | — | — |
alert_muting_rules | Rules that silence alert notifications for matching detectors or dimensions during a time window. | Full refresh | — | — |
dashboards | Dashboards: named collections of charts arranged in a grid. | Full refresh | — | — |
dashboard_groups | Dashboard groups that organize related dashboards and control their permissions. | Full refresh | — | — |
charts | Charts that visualize the output of a SignalFlow program on dashboards. | Full refresh | — | — |
teams | Teams that group organization members and link to detectors and dashboard groups. | Full refresh | — | — |
organization_members | Members of the organization and their roles. | Full refresh | — | — |
metrics | Metric metadata: one row per metric name known to the organization. | Full refresh | — | — |
dimensions | Dimension metadata. Off by default because large organizations can have a very high dimension count | Full refresh | — | — |
metric_time_series | Datapoints published by the SignalFlow program configured on the source, pulled incrementally by time window. Requires the 'SignalFlow program' source field | Incremental, Full refresh | timestamp | — |
Troubleshooting
- Invalid access token or realm – check that the realm matches your organization (the API host is realm-specific) and that the token has API permission and hasn't expired.
metric_time_seriesfails with "requires a SignalFlow program" – edit the source and fill in the SignalFlow program field, or disable that table.- Missing older alert events – the API returns at most 10,000 events per detector, so history beyond that cap isn't synced.
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.