Docs / Incident Communications

Incident Communications

Templates for communicating incidents to users, stakeholders, and regulators. Copy the appropriate template, fill in the placeholders, and publish via the status page, email, and in-app banner. The live system status is available at /status.

Guidelines. Publish within 15 minutes of detection. Update every 30 minutes during active incidents. Use the post-mortem template within 3-5 business days of resolution. Never speculate on unverified information in public communications.

Service Degradation (Partial Outage)

Severity: Medium

Use when one or more services are degraded but the exchange remains partially operational (e.g. API slow, one market stuck, WS intermittent).

Subject: [DEGRADED] Polis Exchange — {SERVICE} experiencing degraded performance

Date: {DATE}
Severity: Medium
Affected Services: {SERVICES}
Status: Investigating

Summary:
{SERVICE} is experiencing degraded performance. Trading remains available but users may experience {SYMPTOMS}.

Impact:
- {IMPACT_1}
- {IMPACT_2}

What we're doing:
- {ACTION_1}
- {ACTION_2}

Workaround:
{WORKAROUND_OR_NONE}

Next update: {NEXT_UPDATE_TIME}

— Polis Exchange Team

Full Outage

Severity: High

Use when the exchange is completely unavailable (engine down, API down, or both). All trading is halted.

Subject: [OUTAGE] Polis Exchange — Trading halted

Date: {DATE}
Severity: High
Affected Services: {SERVICES}
Status: {INVESTIGATING|IDENTIFIED|RECOVERING|RESOLVED}

Summary:
Polis Exchange is currently experiencing a full outage. All trading is halted. {BRIEF_DESCRIPTION}

Impact:
- All markets are unavailable
- Token balances are frozen (no settlement during outage)
- Orders cannot be placed, modified, or cancelled
- WebSocket connections are disconnected

What happened:
{ROOT_CAUSE_OR_INVESTIGATING}

What we're doing:
- {ACTION_1}
- {ACTION_2}

Estimated recovery: {ETA_OR_INVESTIGATING}

Token safety:
All token balances are preserved. No settlement will occur during the outage. Trading will resume when the system is restored.

Next update: {NEXT_UPDATE_TIME} (or sooner if status changes)

— Polis Exchange Team

Security Incident

Severity: Critical

Use when a security breach is suspected or confirmed (unauthorized access, key compromise, fund loss, data breach).

Subject: [SECURITY] Polis Exchange — Security incident detected

Date: {DATE}
Severity: Critical
Incident ID: {INCIDENT_ID}
Status: {DETECTED|CONTAINED|ERADICATED|RECOVERED}

Summary:
We have detected a security incident involving {BRIEF_DESCRIPTION}. {CONFIRMED_OR_SUSPECTED}.

Immediate actions taken:
- Affected systems isolated
- {ACTION_1}
- {ACTION_2}

Impact assessment:
- User funds: {FUNDS_STATUS}
- User data: {DATA_STATUS}
- Trading operations: {TRADING_STATUS}

What you should do:
- {USER_ACTION_1}
- {USER_ACTION_2}
- If you used the same password elsewhere, change it immediately

We are conducting a full investigation and will provide updates as we have confirmed information. We will not speculate on unverified details.

Law enforcement / regulators: {NOTIFIED_OR_PENDING}

Next update: {NEXT_UPDATE_TIME}

— Polis Exchange Team

Post-Mortem Template

Post-Incident

Use 3-5 business days after any High/Critical incident is resolved. Publish internally and to affected users.

Post-Mortem: {INCIDENT_TITLE}

Incident ID: {ID}
Date of incident: {DATE}
Duration: {DURATION}
Severity: {SEVERITY}
Authors: {NAMES}

1. Summary
{2-3 SENTENCE SUMMARY OF WHAT HAPPENED AND IMPACT}

2. Impact
- Duration: {DURATION}
- Users affected: {COUNT_OR_PERCENTAGE}
- Services affected: {LIST}
- Financial impact: {AMOUNT_OR_NONE}
- Data impact: {DESCRIPTION_OR_NONE}

3. Timeline (all times UTC)
- {TIME}: {EVENT}
- {TIME}: {EVENT}
- {TIME}: Detection — {HOW_DETECTED}
- {TIME}: {RESPONSE_ACTION}
- {TIME}: {RESOLUTION_ACTION}
- {TIME}: Incident declared resolved

4. Root Cause
{DETAILED_TECHNICAL_EXPLANATION}

5. Contributing Factors
- {FACTOR_1}
- {FACTOR_2}

6. What Went Well
- {POSITIVE_1}
- {POSITIVE_2}

7. What Went Poorly
- {NEGATIVE_1}
- {NEGATIVE_2}

8. Action Items
| Priority | Action | Owner | Due |
|----------|--------|-------|-----|
| P1 | {ACTION} | {OWNER} | {DATE} |
| P2 | {ACTION} | {OWNER} | {DATE} |

9. Lessons Learned
{WHAT_WE_LEARNED}

10. Appendix
- Monitoring screenshots
- Logs excerpts
- Architecture diagrams (if relevant)

Severity Levels

Critical

Full outage or security incident. All hands. Update every 15 min.

High

Major service degraded. Trading impacted. Update every 30 min.

Medium

Partial degradation. Workaround available. Update every hour.

Low

Minor issue, no user impact. Resolve in next maintenance window.

Communication Channels

Status page (/status) — primary public status indicator
In-app banner — dismissible banner on all pages for active incidents
Email — all registered users for High/Critical incidents
Direct message — affected users (e.g. token holders) for token-affecting incidents
Regulator notification — FCA if required by UK financial regulations

System Status →← Docs