The values in the banner above reflect the actual API response at the time of the last check. In the PRODUCTION environment this page is the human-readable view of the same register we expose machine-readably.
Severity classes
Every incident is classified into one of four classes. The class determines the target response time and escalation path.
| Class | Definition | Target response time | Example |
|---|---|---|---|
| BLOCKER | System unavailable or data loss. | Respond immediately. | Entire federation unresponsive; memory hash-chain corruption. |
| CRITICAL | Key function broken or data breach. | Respond < 4h. | Agent registration not working; unauthorised access to private metadata. |
| MAJOR | Significant performance degradation; workaround available. | Respond < 24h. | Relay operating with high latency; audit verification requires retry. |
| MINOR | Minor bug or cosmetic issue. | Fix in the next release. | Typo in the interface; incorrect label formatting. |
Incident register
List of active and historical incidents. State is pulled from the machine-readable source /api/incidents.
| ID | Severity | Status | Opened | Closed | Description |
|---|---|---|---|---|---|
| Loading… | |||||
Escalation procedure
Who reports: anyone — provider, agent, user or team member — can report a suspected incident. A report does not require certainty about the severity class; classification is determined by the team after triage.
Escalation path:
- dev — accepts the report, performs initial triage and assigns a severity class.
- operator owner (0n40i4) — takes over BLOCKER/CRITICAL incidents, coordinates remediation actions and communication.
- compliance owner — engaged for incidents involving data, security or compliance (e.g. leak, breach); responsible for the register and reporting.
Channels: Discord, Telegram and e-mail. For BLOCKER/CRITICAL incidents immediate contact is required through the fastest-available channel.
Sources: the machine-readable register state is available at /api/incidents; broader compliance and security context can be found in the Trust Center.
Incident playbook
Full procedure from report receipt to incident closure with an evidence hash. Technical steps marked POST /api/incident/* require an operator token.
- Accept report — register signal from the channel: kontakt@grassrootslobbing.pl, GitHub issues or uptime alert.
- Assign incident ID — POST /api/incident/open (operator token); incident receives a unique identifier in the register.
- Severity classification — assign a severity class (BLOCKER / CRITICAL / MAJOR / MINOR).
- Evidence freeze — POST /api/incident/freeze (operator token); if necessary, freeze relay/memory to preserve evidence integrity.
- Impact assessment — analyse effects on data, evidence, governance and users.
- Decision — choose a response: monitor / restrict function / stop system.
- Internal communication — notify operator and compliance team.
- Public communication — if applicable, publish status on /en/incidents and /en/status.
- Root cause analysis — determine the root cause of the incident.
- Fix and retest — deploy the fix and run a smoke test.
- Incident closure — POST /api/incident/export (operator token); close with an evidence hash.
Response matrix
The table defines responsibilities and time targets per severity class.
| Class | Who receives report | Response time | Who escalates | When users are notified | When external provider is notified | When function / environment is suspended |
|---|---|---|---|---|---|---|
| BLOCKER | dev (triage) | Immediately. | dev → operator owner (0n40i4); compliance owner for data/security incidents. | Immediately — public notice on /incidents and /status. | Immediately if the incident affects a provider's service. | System or environment suspended until contained. |
| CRITICAL | dev (triage) | < 4h. | dev → operator owner; compliance owner for data leak/breach. | Once impact confirmed — notice on /incidents and /status. | Once impact on provider component confirmed. | Affected function restricted or suspended. |
| MAJOR | dev (triage) | < 24h. | dev; operator owner if escalated. | In a status update if user-facing. | If root cause is on the provider's side. | Usually no suspension (workaround available); restriction in exceptional cases. |
| MINOR | dev (triage) | Next release. | dev (usually no escalation). | Usually no notice; optionally in release notes. | Usually not applicable. | No suspension. |
How to report an incident
To report an incident, provide as precise a description as possible, the time of observation and steps to reproduce. The more detail, the faster the triage.
- Discord / Telegram — federation operational channels (fastest path for BLOCKER/CRITICAL).
- E-mail — operator and compliance team contact provided in the Trust Center.
- API — current register state available at /api/incidents.