Incidents

Incidents are first-class managed objects for recording security and operational events in the Polycrate API: core fields, status machine, scope, automatic creation from provider status feeds, UI, conditions and notifications.

Incidents

An Incident is a first-class managed object for keeping records of security and operational events (ISMS / VA-IM). It is not a Note kind — Notes can, however, be linked as a source or post-mortem.

Core Fields

Field Meaning
status reported → investigating → contained → resolved → reviewed
kind among others upstream-provider for automatic provider incidents
criticality low / medium / high
organization / workspace Scope; organization=null = system-wide
pop / affected_pops Primary PoP + canonical PoP set
provider_entity Linked provider
affected_hosts / affected_volumes Affected resources
downtimes Linked downtimes
source_note / source_datasource Origin from provider status
Embedded Note Description / evidence

Status Machine

  • Forward only (skipping is allowed, e.g. reported → resolved)
  • reviewed is terminal
  • No separate acknowledge — taking over = status change from reported

Scope

Scope Visibility
System-wide always visible to authorized users
Organization / Workspace within the respective tenant

Automatic Creation (Provider Status)

DataSources (rss, otc-status, webhook) produce provider-status Notes. The AI evaluation can:

  • create/update Maintenances
  • create Incidents (kind=upstream-provider, often system-wide)
  • link hosts/volumes/PoPs via matching (provider_id, hostname, cloud_provider_volume_id, …)

A manual re-scan of a Note or DataSource is possible if the classification needs to be updated.

UI

  • List under Operations → Incidents
  • Detail: classification, PoP/provider/source, embedded Note, tabs for downtimes and affected hosts/volumes/PoPs, Activity Timeline

Conditions & Notifications

  • INCIDENT_REVIEW_OVERDUE (WARNING) if resolved remains too long without reviewed
  • Notifications incident_opened / incident_closed (idempotent)

Scope Boundaries

  • Zammad/tickets: at most a manual reference_url — no embedded ticket system
  • Downtimes remain the technical outage object; incidents are the formal incident record
  • Post-mortems can still be kept as Notes kind=post-mortem

Related Topics