Incidents and tickets

An incident timeline carries the vendor’s lifecycle and yours, never merged. This page says what each field means, what the API refuses, and how an incident becomes a ticket.

Two lifecycles

open_for_us is computed from ours alone: not cleared by us and not snoozed. A vendor marking an incident resolved changes upstream.status and nothing else. When a vendor reopens an incident you had cleared, it comes back as unreviewed; while they only post updates, your status stands.

What you may claim

• customer_impact: confirmed or suspected needs an impact_note that names the evidence: the log line, the metric, the alert, the user report, with time and source. The API refuses the patch otherwise.
• not_observed deserves a note saying what you checked.
• Nothing is ever inferred from the vendor’s severity. A critical upstream incident is still unknown for you until checked.

curl -X PATCH https://api.changelog.observer/v1/incidents/<incident_id> \
  -H "Authorization: Bearer <key>" -H "Content-Type: application/json" \
  -d '{"our_status": "affected", "customer_impact": "confirmed",
       "impact_note": "Checkout 5xx from 10:05 UTC in Datadog, service payments-api", "acknowledge": true}'

Bulk actions and mutes

POST /v1/projects/{id}/incidents/bulk applies one action to many timelines: acknowledge, affected (sets confirmed impact; add the evidence after), cleared, not_observed, mute_24h, mute_7d. A mute belongs to the dependency: new events from it go to the digest only, for the period. A snooze (muted_until on the incident) hides it from “open for us” for the period.

Maintenance windows

A timeline with scheduled_for is a maintenance window. The dashboard lists them under Incidents → Upcoming maintenance, soonest first, with a planned, in progress or completed state; the API lists them with GET /v1/workspace/maintenance and the per-project equivalent, fourteen days ahead by default (from and to widen it). They never appear in the incident lists.

A ticket-ready summary

GET /v1/incidents/{id}/summary?format=text|markdown composes one block of text for a ticket: a title (“Stripe: Elevated API errors”), both lifecycles, project and dependency, first seen and last update, the dashboard link, your impact note, every update in the vendor’s own words oldest first (repeats left out, capped at twenty), and a closing line saying customer impact is never inferred. Vendor text is escaped in Markdown so it cannot become links or headings. The dashboard’s incident page has “Copy as text” and “Copy as Markdown” for the same.

Push to a ticket system

First add the ticket system as a destination (once per project, with a destinations:write key or from Rules & destinations in the app):

curl -X POST https://api.changelog.observer/v1/projects/<project_id>/destinations \
  -H "Authorization: Bearer <key>" -H "Content-Type: application/json" \
  -d '{"type": "github_issues", "name": "Platform issues",
       "config": {"repo": "acme/platform", "labels": ["vendor-incident"]},
       "credential": "github_pat_…"}'

The credential is sealed at rest (AES-256-GCM under a key derived from the platform secret, bound to the destination) and never returned; credential_set_at says one exists, and PATCH …/destinations/{destId} with credential replaces it. Ticket systems never receive routed events; only an escalation reaches them.

Then, for an incident:

curl -X POST https://api.changelog.observer/v1/incidents/<incident_id>/escalate \
  -H "Authorization: Bearer <key>" -H "Content-Type: application/json" \
  -d '{"destination_id": "dst_…"}'

The response carries system, external_key (PAY-123, ENG-42, #17, a Statuspage incident id), external_url and existing. One escalation per incident and destination: calling again returns the first one. The body is the summary above, as text for Jira (as an Atlassian document) and Statuspage, as Markdown for Linear and GitHub; format overrides. A refusal from the vendor comes back as 502 escalation_failed with their status and the first words of their answer. Every escalation is audited and listed on the incident (escalations) and in the dashboard’s Ticket column.