figma guide
Designing customer incident status page and communication UI in Figma: components, subscriptions, and updates
Design customer-facing incident status page UI in Figma with component health, incident timelines, email/SMS templates, subscriptions, and postmortem publishing for SaaS teams.
- Published
- Updated
- Jul 27, 2026
- Read time
- 9 min
- Level
- Intermediate
Quick answer
Customer incident status page UI is how SaaS teams earn trust during outages—clear component health, honest timelines, subscription options, and postmortems without leaking internals. Design a public status page with component groups and history; an incident composer synced to internal war room state; subscriber notification templates (email, SMS, webhook); and a postmortem publish flow with redaction. Start from the Figma guides hub and pair with BCP/DR planning, breach notification, post-incident review, inline alerts, and Dev Mode handoff.
Who this is for
- Product designers building trust centers, public status pages, and in-app incident banners for B2B SaaS.
- Design system teams aligning operational status colors, incident severity badges, and timeline components with badges, toasts, and navigation.
- Engineering and comms teams implementing war-room-to-public sync, subscriber delivery, and redacted postmortem export.
Status page hub (public + admin)
StatusAdmin — acme.status.example.com
├── Public preview: All systems operational · 3 components degraded history (90d)
├── Active incident: INC-PUB-2026-041 · Investigating · Last update 4m ago
├── Actions: [ New incident ] [ Maintenance window ] [ Publish postmortem ] [ Preview subscriber email ]
├── Tabs: Components · Incidents · Subscribers · Templates · Settings
└── Sync: War room INC-2026-0891 · Comms mode: Customer-facing only| Surface | Purpose |
|---|---|
| Public status page | Component health, active incidents, history |
| Incident composer | Draft updates; approval before publish |
| Subscriber management | Email/SMS/webhook preferences |
| Templates | Pre-approved copy blocks by severity |
| Settings | Custom domain, branding, RSS/Atom |
Verdict: Admin composer is downstream of internal war room—never the source of truth for technical state. Sync status labels: Investigating → Identified → Monitoring → Resolved.
Component groups and health states
ComponentList — Customer-facing
├── API (Critical) · Operational · Uptime 99.97% (90d)
├── Dashboard (Critical) · Operational
├── Webhooks (High) · Degraded performance · Linked INC-PUB-041
├── File exports (Medium) · Operational
├── EU region (Critical) · Maintenance scheduled 2026-08-02 02:00 UTC
└── [ Reorder ] [ Group under "Platform" ] [ Hide internal-only ]| State | Color token | Public copy |
|---|---|---|
| Operational | Success / green | ”All systems operational” |
| Degraded | Warning / amber | ”Experiencing degraded performance” |
| Partial outage | Error / red | ”Partial outage” |
| Major outage | Error / red (bold) | “Major outage” |
| Maintenance | Info / blue | ”Scheduled maintenance” |
Map internal BCP service tiers to public components—customers do not need 47 microservices exposed.
Use semantic color tokens for light/dark status page themes.
Public incident timeline
PublicIncident — INC-PUB-2026-041 · Webhooks degraded
├── Status banner: Degraded · Started 2026-07-27 14:22 UTC · Duration 47m
├── Timeline:
│ 14:22 — Investigating increased webhook delivery delays
│ 14:41 — Identified issue with outbound queue worker
│ 15:02 — Fix deployed; monitoring recovery
│ 15:09 — Resolved; deliveries returning to normal
├── Affected: Webhooks only · API and Dashboard unaffected
├── Subscribe: [ Email ] [ SMS ] [ RSS ] [ Slack webhook ]
└── Postmortem: Not yet published| Element | UI detail |
|---|---|
| Status header | Current phase + start time + duration (live updating) |
| Update entries | Newest first or oldest first—pick one; sticky setting |
| Affected components | Multi-select chips; auto from war room |
| Impact scope | Plain language; no internal hostnames |
| Subscribe CTAs | Above fold on mobile |
| Maintenance vs incident | Distinct page template—scheduled banner style |
Each published update triggers subscriber notifications—show pending send queue in admin.
Incident composer (internal → public)
IncidentComposer — Draft update #3
├── Linked war room: INC-2026-0891 · Internal phase: Monitoring
├── Public status: Monitoring · Map: Internal Monitoring → Public Monitoring
├── Message (plain language): We deployed a fix and are watching webhook delivery rates.
├── Affected components: [x] Webhooks · [ ] API · [ ] Dashboard
├── Notify: [x] Email subscribers · [x] SMS (Critical only) · [ ] Webhook
├── Approval: Required from Comms lead · Legal review: Not required
└── [ Schedule publish ] [ Publish now ] [ Save draft ]| Guardrail | Why |
|---|---|
| Approval gate | Prevents engineer raw notes going public |
| Redaction lint | Flag internal IDs, employee names, CVE detail |
| Template snippets | ”Investigating”, “Identified”, standard impact phrases |
| Drill mode lock | When BCP drill active—block real sends |
| Breach split | Data breach uses regulatory comms—separate workflow |
| Rollback | Unpublish or amend with correction notice |
Composer shows side-by-side preview: admin draft vs public render (mobile + desktop frames).
Subscriber and notification preferences
SubscribeModal — Public
├── Email: user@company.com · Verify via OTP
├── SMS: +1 *** *** 4521 · Critical incidents only
├── Webhook: https://hooks.customer.com/status · JSON payload docs
├── Preferences: All incidents · Only components I use · Critical only
└── Unsubscribe link in every message — CAN-SPAM / GDPR footerSubscriberAdmin
├── Total verified: 12,402 · SMS: 891 · Webhooks: 234
├── Segment: Enterprise customers · Auto from account tier API
├── Rate limit: Max 1 SMS/customer/hour unless Major outage
└── [ Test send ] [ Export subscriber audit log ]| Channel | Design note |
|---|---|
Subject line pattern: [Acme Status] Webhooks — Monitoring | |
| SMS | Short URL to status page; no technical detail |
| Webhook | JSON schema versioned; link webhooks admin docs |
| RSS/Atom | For power users and status aggregators |
| In-app banner | Reuse inline alert on logged-in app |
Verification flow pairs with email OTP UI patterns.
Maintenance windows
MaintenanceComposer
├── Title: Database index upgrade — EU region
├── Schedule: 2026-08-02 02:00–04:00 UTC · Reminder 24h and 1h before
├── Expected impact: Dashboard read-only; API writes queued
├── Components: EU region · Dashboard (read-only badge)
├── Public listing: Scheduled maintenance (not incident)
└── Auto-resolve: Publish "Completed" at end time unless extendedMaintenance uses blue/info styling—distinct from red incident banner to reduce alert fatigue.
Extension flow: convert to incident if maintenance overruns—preserve timeline continuity.
Postmortem publish flow
PostmortemPublish — from PIR INC-2026-0891
├── Source: Executive summary v2 (Legal approved)
├── Redaction preview: Internal names removed · Vendor names generalized
├── Sections: Summary · Timeline · Root cause (customer-safe) · Remediation
├── Publish to: Status page history · Email all subscribers · Trust center PDF
├── Schedule: Publish 2026-07-28 10:00 UTC (after peak traffic)
└── [ Legal approval ✓ ] [ Comms approval ✓ ] [ Publish ]| Section | Customer-safe rule |
|---|---|
| Summary | Business impact in plain terms |
| Timeline | Public updates only—no internal war room entries |
| Root cause | System category (config, capacity, third party)—no blame |
| Remediation | What customers should expect next |
| Exclude | Individual names, exact exploit detail, pre-patch vulnerability |
Import from PIR executive summary—never raw RCA tree.
In-app status integration
| Surface | Pattern |
|---|---|
| Global banner | Active Major outage only—link status page |
| Component badge | Settings → “Service health” with same component list |
| API status header | Optional X-Status: degraded docs for developers |
| Support widget | Prefill incident ID for support tickets |
| Trust center | Historical uptime + postmortem archive |
Use responsive frames for mobile banner height—do not cover primary nav actions.
Integration with internal security ops
| Internal module | Customer status usage |
|---|---|
| War room | Source incident phase; comms lead role publishes |
| BCP/DR runbook | Step “Update status page” with composer deep link |
| Breach notification | Separate regulated disclosure—do not merge with availability incident |
| PIR | Feed postmortem publish |
| Audit log | Who published each public update |
| Notification prefs | Align marketing vs operational email categories |
Security incidents without customer impact may stay internal-only—composer shows “No public incident” toggle with default off for data-only events until Legal approves.
Status page templates by audience
| Template | Tone | Pairs with |
|---|---|---|
| Developer API SaaS | Technical component names, webhook detail | API keys |
| Business app SaaS | Feature names (Reports, Billing) | Account dashboard |
| Multi-tenant B2B | Region + tenant-agnostic messaging | SSO |
| Marketplace / platform | Seller + buyer impact sections | Vendor risk |
| Enterprise trust center | Uptime SLAs, postmortem PDF archive | Security posture |
Pick one primary template—avoid mixing developer jargon with consumer copy on same page.
Handoff checklist (Dev Mode)
- Component schema — public name, internal ID, tier, display order.
- Incident lifecycle — public phase enum and war room mapping table.
- Update object — timestamp, message markdown subset, affected components.
- Notification payloads — email HTML, SMS length, webhook JSON v1.
- Approval roles — comms required; legal conditional on breach flag.
- Redaction rules — regex list for composer lint warnings.
- Drill mode — global flag blocking external sends.
- Accessibility — status colors not sole indicator; screen reader labels for timeline.
- Uptime calculation — formula tooltip on public history charts.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Public updates ahead of internal sync | Contradictory messages | War room phase drives composer defaults |
| Too many components | Customer confusion | Group into 5–9 public components |
| Technical jargon in SMS | Panic, support flood | Link to status page; plain language |
| No subscribe on mobile | Users refresh Twitter instead | Sticky subscribe CTA |
| Publishing raw PIR | Leak internals, legal risk | Redacted postmortem flow |
| Missing maintenance distinction | Cry-wolf on incidents | Separate maintenance template |
| No approval on first publish | Engineer mistake goes live | Comms approval gate |
| Breach on status page only | Regulatory gaps | Route to breach workflow |
| Forgetting in-app banner | Logged-in users unaware | Major outage banner component |
| No audit trail | Trust disputes | Log publisher + diff in audit log |
Recommended workflow
- Design public status page with component health, incident timeline, and subscribe CTAs.
- Build incident composer with war room sync, approval, and redaction lint.
- Create notification templates for email, SMS, and webhook channels.
- Add maintenance window flow distinct from incident styling.
- Wire postmortem publish from PIR executive summary with Legal gates.
- Spec in-app banner and trust center links in Dev Mode.
FAQ
Status page vs breach notification?
Status page covers availability and performance customers experience. Breach notification covers personal data exposure with regulatory timelines—different templates, approvers, and archives.
How much detail in public root cause?
Category-level (misconfiguration, upstream provider, capacity)—enough to be credible, not enough to aid attackers. Full detail stays in internal PIR.
Sync with war room?
War room Comms lead role gets composer access; phase changes suggest draft update text—human approves before send.
SMS for every update?
Default Critical/Major only or user opt-in—rate limit to prevent alert fatigue.
Uptime percentages?
Show 90-day rolling unless SLA defines otherwise; tooltip explains calculation and excluded maintenance.
Next steps
- Design business continuity and disaster recovery planning UI in Figma — DR runbook step hooks into status updates
- Design security operations shift handover and war room UI in Figma — internal source for public incident phase
- Design post-incident review and root cause analysis UI in Figma — feed redacted postmortems
- Design breach notification and regulatory reporting UI in Figma — separate regulated customer comms
- Design inline alerts and banners in Figma — in-app incident banner patterns
§ Keep reading