Public Status Page Mission and Trust Contract
Public Status Page Mission and Trust Contract — public status page system design
Public Status Page Mission and Trust Contract
Context (sec-001)
Interviewers at Atlassian, Better Stack, and Instatus expect you to treat the public status page as a trust surface, not a monitoring backend. Section 001 (Public Status Page Mission and Trust Contract) anchors mission.
When mission fails, customers learn about outages from Twitter before your page updates—brand damage exceeds technical MTTR.
Operational invariant for mission: published customer text is append-only; corrections are new timeline entries, never silent edits.
Capacity anchors for this slice: 18k hosted pages, 220M monthly visitors, 14M subscribers, incident publish p95 < 1s after comms approval.
Failure drill (mission): if notification workers lag, public HTML may still be fresh via CDN while email is delayed—show both timestamps honestly.
Mechanisms
- Component graph — Pages expose ordered components; dependency edges roll up child outages to parent groups (e.g., API degrades Mobile App).
- Incident lifecycle — Draft → scheduled publish → investigating → identified → monitoring → resolved; only Comms Lead may publish externally visible text.
- Read amplification — One incident edit triggers CDN purge, RSS regeneration, embed JSON bump, and millions of notification jobs—design the write path async.
- Custom domains —
status.customer.comterminates TLS at edge; host header maps totenant_idbefore any query executes.
Operational invariants
- Tenant isolation — every row and cache key includes
tenant_id; cross-tenant host mapping is impossible at the router. - Human gate — automated probe flaps do not auto-publish customer-facing major outage copy without role approval (configurable per tenant).
Phase emphasis (order 1)
For mission, articulate why the decision buys trust or operability, not merely what service you picked.
Failure and edge cases
During mission outages: serve last-known-good snapshot from edge KV; badge page as potentially stale; never 500 the public read path.
Capacity snapshot
| Signal (mission) | Target |
|---|---|
| Public read p95 | < 120ms at edge |
| Publish to edge visible | < 60s |
| Notification enqueue | < 5s |
| Uptime rollup job | < 2m lag |
Reference implementations
1 public final class Status001Policy { 2 private static final Map<String, Set<String>> INCIDENT = Map.of( 3 "investigating", Set.of("identified", "monitoring"), 4 "identified", Set.of("monitoring", "resolved"), 5 "monitoring", Set.of("resolved") 6 ); 7 public boolean publishTransition(String from, String to, boolean commsApproved) { 8 return commsApproved && INCIDENT.getOrDefault(from, Set.of()).contains(to); 9 } 10 }
1 def subscriber_digest(page_id: str, incident_id: str, channel: str) -> str: 2 import hashlib 3 raw = f"{page_id}|{incident_id}|{channel}".encode() 4 return hashlib.sha256(raw).hexdigest()[:20] 5 6 def edge_cache_key(hostname: str, path: str, revision: int) -> str: 7 return f"status:v3:{hostname}:{path}:r{revision}"
1 export interface PublicStatusSnapshot { 2 pageId: string; 3 overall: "operational" | "degraded" | "partial" | "major" | "maintenance"; 4 asOf: string; 5 components: Array<{ id: string; status: string }>; 6 } 7 8 export function etagFor(snapshot: PublicStatusSnapshot): string { 9 return `W/"${snapshot.pageId}-${snapshot.asOf}"`; 10 }
Why interviewers care
Status Page interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.
Interview checkpoint
Name one failure story for Public Status Page Mission and Trust Contract that proves you understand real outages, not happy-path diagrams.
Key Highlights
- •sec-001: mission — public read path must never hard-fail during origin issues.
- •Publish pipeline for mission is async: OLTP commit → outbox → purge → fanout.
- •Tenant-scoped host mapping is mandatory before any mission query executes.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me walk the mission path: probe → draft → human publish → edge purge → notifications."
- "I will quantify mission with peak RPS, subscribers, and publish latency before picking vendors."