incident.io setup

​

Part 1: incident.io Data Ingestion

​

Step 1: Create an incident.io API Key

1. Go to: https://app.incident.io/~/settings/api-keys
2. Click Add new API key
3. Name: ConfigView
4. Grant the key the view / read permissions for every area you want inventoried — incidents, alerts, on-call schedules, the catalog, and organisation settings. ConfigView never writes, so no create, edit or delete permission is needed.
5. Leave the key account-wide rather than scoping it to a team, unless you deliberately want ConfigView to see only that team’s data. A team-scoped key silently returns a subset, which looks identical to a small tenant.
6. Click Create and copy the key — you will only see it once

On least privilege. Listing API keys and reading the IP allowlist need organisation-admin-level scope. If you would rather not grant that, everything else still works: those two collectors record a skip instead of failing, and the health check reports them as gated rather than broken.

​

Step 2: Add the Key to ConfigView

1. Go to your ConfigView dashboard: https://{companyname}.configview.com/admin/secret/
2. Click Add Secret
3. Secret name: INCIDENTIO_API_KEY
4. Secret value: Paste the key from Step 1
5. Click Save

​

Step 3: Enable the incident.io App in ConfigView

1. Go to: https://{companyname}.configview.com/admin/cron/
2. You should see incident.io in the list of available apps
3. Select the scripts you want to run — all 50 are listed below, grouped by area
4. Click Save

Dependencies. Thirteen collectors read a parent table before they can run: anything per-incident needs Incidents first, per-user needs Users, catalog entries need Catalog Types, and so on. The scheduler enforces the order, but if you enable a child without its parent the child records “no rows in parent table yet” and does nothing until the parent has run once.

• Users — Every responder including deactivated ones, with base role, custom roles, and which response and on-call seats they consume.
• Teams — Teams and their linked catalog entry — the unit incident.io scopes API keys, alert sources, and escalation paths to.
• Team Members — One row per person per team, so team membership is joinable instead of buried in a nested list.

• Incidents — The full incident record with severity, status, type, reporter, Slack channel, and the workload minutes each one consumed.
• Incident Updates — Every status and severity change on an incident, with who made it and when.
• Incident Statuses — The tenant’s configured statuses and their categories.
• Incident Types — Incident types, their owning teams, and whether they force private incidents.
• Incident Roles — Role definitions such as Lead and Communications, with the instructions given to whoever is assigned.
• Incident Timestamps — The timestamp definitions the tenant measures incidents against.
• Severities — Severity levels and their ranking.
• Custom Fields — Custom field definitions, their types, and any catalog type they draw values from.
• Custom Field Options — The selectable values behind every option-backed custom field.
• Actions — In-incident actions with assignee and completion state.
• Follow-ups — Post-incident follow-ups with assignee, owning team, priority, and any linked Jira or GitHub issue.
• Postmortem Documents — Postmortem metadata and document links. Document contents are deliberately not collected.
• Incident Relationships — Links between related and duplicate incidents.
• Incident Attachments — External resources pinned to an incident, such as dashboards, tickets, and pull requests.
• Incident Participants — Who took part in each incident, split into active responders and passive observers.
• Incident Participant Workloads — Minutes each responder spent per incident, broken out into working, late, and sleeping hours.

• Alerts — Alerts with source, status, deduplication key, and resolution time.
• Alert Sources — Every configured alert source with its type and heartbeat settings. Webhook secret tokens are never stored.
• Alert Routes — Alert routes and whether each one is currently enabled.
• Alert Attributes — The attribute schema alerts are enriched against.
• Incident Alerts — The join between an alert and the incident it was escalated into.
• Alert Notes — Notes left on alerts, with their author.

• Escalations — Escalations with status, priority, the path used, and the alerts and incidents they relate to.
• Escalation Paths — Escalation path configuration including levels, repeat behaviour, and working hours.
• Escalation Path Responders — Who is currently reachable on each escalation path, as a flat table.
• Schedules — On-call schedules with timezone, owning teams, rotation count, and holiday configuration.
• Schedule Rotations — Rotation configuration per schedule: scheduling mode, handover timing, layers, and the users in the pool.
• Schedule Current Shifts — Who is on call right now on every schedule.
• Schedule Entries — The resolved rota after overrides are applied — who was actually on call, and when.
• Schedule Overrides — Cover and swap overrides against each schedule.
• Schedule Sync Targets — Slack user groups kept in sync with an on-call schedule.
• User Notification Methods — Each responder’s phone, email, and app notification methods, including whether the method is actually usable.
• User Notification Rules — The escalation rules that decide how and how quickly each responder gets paged.
• User Paging Providers — Which responders are still paged through a legacy provider rather than incident.io.

• Catalog Types — Catalog type definitions — the schema behind the services, environments, and vendors the tenant models.
• Catalog Type Attributes — Every attribute on every catalog type, with its mode and backing resource type.
• Catalog Entries — The catalog itself: each entry with its aliases, external ID, and attribute values.
• Catalog Resources — The attribute types the catalog can reference.

• API Keys — Every API key with its granted roles, team scope, creator, and last-used date — the dormant-credential question in one table.
• API Key Roles — One row per key per granted role, so privilege is a WHERE clause rather than a string search.
• Secrets — Metadata for credentials stored in incident.io for its own integrations. Only the last four characters are ever returned.
• IP Allowlist — Whether IP allowlisting is enabled and which ranges are permitted.
• Workflows — Automation workflows, their triggers and steps, and whether each one reaches private incidents.

• Status Pages — Public status pages and their URLs.
• Status Page Incidents — What was communicated publicly, with component impacts and each published update.
• Status Page Maintenances — Scheduled maintenance published to a status page, with affected components.
• Maintenance Windows — Internal alert-suppression windows — including any that were never closed.

​

Step 4: Verify

1. Go to: https://{companyname}.configview.com/admin/status/
2. Run the incident.io health check
3. The core checks must pass:
   • Secret Manager access (INCIDENTIO_API_KEY)
   • incident.io API auth (/v1/identity) — this also prints the key’s name, whether it is account-wide or team-scoped, and the roles it holds
   • Users endpoint (/v2/users)
   The remaining checks report ok when reachable or skip with a plan/scope note. A skip is expected on tenants without On-call or Status Pages, and on keys without org-admin scope.

​

Data Tables

​

Identity

​

Incidents

​

Alerting

​

On-call

​

Catalog

​

Governance

​

Status pages & maintenance

​

Snapshot Convention

SELECT * FROM incidentio_incidents
WHERE run_at = (SELECT MAX(run_at) FROM incidentio_incidents);

​

Rate Limits

First run on a large tenant. The per-incident collectors fan out over incidents updated in the last 90 days. On a tenant with thousands of live incidents that is the longest part of the sync. Widen or narrow the window in incidentio_get_incident_*.py if you need a different history depth.

​

What ConfigView Deliberately Does Not Collect

​

Troubleshooting