A public status page can support a dated record of disclosed incidents, affected components, updates, and recovery. It cannot support a fair universal reliability ranking from incident counts alone. Compare equivalent windows, components, severities, durations, recurrence, and disclosure practices, then connect the record to a real buyer or operating decision.
What this guide covers
- the fields required for an incident ledger;
- how to model an incident as state, not page churn;
- fair comparison rules and disclosure caveats;
- a reliability decision memo.
Model the incident, not each page edit
Public pages such as Cursor status, Bubble status, Clay status, and Bolt status publish operational records with different component and disclosure structures.
One incident may move through:
investigating → identified → monitoring → resolvedA raw diff system can misread each transition as a separate outage or treat “incident text removed” as a new event. Use the stable incident identifier, affected component, and state transitions.
Capture comparable incident fields
- provider and product/component;
- incident identifier and title;
- first observed and stated start time;
- state changes and update times;
- stated impact/severity;
- affected region or feature;
- mitigation and resolution time;
- final duration, where supportable;
- repeated or related incident linkage;
- source URL and capture health;
- buyer workflow affected.
Preserve the provider's wording. Do not convert “degraded performance” into “outage” unless the source or your own measured impact supports it.
Separate four reliability questions
Availability
Was the service or component reachable and usable?
Performance
Did latency, errors, queues, or delayed logs impair the workflow?
Scope
Which component, region, account type, or percentage of traffic was affected?
Recovery
How quickly did detection, communication, mitigation, and resolution occur?
One headline rarely answers all four.
Do not compare raw incident counts
Counts are misleading when providers differ in:
- component granularity;
- disclosure threshold;
- incident grouping;
- update frequency;
- customer base and traffic;
- maintenance reporting;
- historical retention;
- status platform migrations.
Ten transparent, narrow component incidents are not automatically worse than two vague major incidents. A provider that discloses more can look worse in a naive table.
Build an equivalent-window ledger
Choose a decision-relevant window, such as the last 30 or 90 days, and classify only incidents affecting the comparable workflow.
| Field | Incident A | Incident B |
|---|---|---|
| Component/workflow | ||
| Stated severity | ||
| Start/detection | ||
| First public update | ||
| Mitigation | ||
| Resolution | ||
| Duration | ||
| Recurrence | ||
| Buyer impact | ||
| Disclosure caveat |
Calculate duration only when timestamps are comparable. Mark unknown rather than fabricating an interval from capture times.
Corroborate the buyer impact
A status record should trigger a strategic review only when it affects a current decision:
- vendor selection or renewal;
- a displacement conversation;
- architecture/fallback design;
- launch readiness;
- SLA or support negotiation;
- customer communication;
- dependency concentration.
Use your logs, support cases, and contract terms. The public incident is one part of the operating record.
Track recurrence carefully
Repeated incidents can indicate a pattern, but require consistent component identity and cause language. Avoid merging unrelated provider dependencies or different product surfaces merely because the titles are similar.
Record:
- same component;
- same stated cause, if disclosed;
- interval between events;
- whether a permanent remediation is stated;
- whether your workload was affected each time.
Reliability decision memo
# Reliability review: [Provider/component]
Window:
Decision/workload:
Primary status URL:
## Incident ledger
| Date | Component | Severity | Duration | Our impact |
|---|---|---|---|---|
## What the public record supports
## Disclosure/comparability limits
## Internal evidence
- logs:
- support cases:
- SLA/contract:
## Decision
Owner:
Fallback/mitigation review:
Vendor questions:
Outcome:Use the EXVIV company directory to find status-source coverage, the market map to select comparable providers, and Evidence Compare to keep reliability records beside other commercial signals. The monitoring guide covers capture and review.
Related EXVIV research
- Public signals that reveal competitive strategy
- How to read a competitor changelog
- What competitor job postings can—and cannot—tell you
Sources and further reading
Method note
This method analyzes public disclosures. It is not an uptime measurement service, SLA audit, or complete reliability comparison. Provider disclosure policies and product traffic differ; combine public incidents with your own observed workflow data.