Platform usage
The core workflows: investigating an incident, reviewing hypotheses, checking and approving actions, and producing post-incident reports.
Investigate an incident
Every incident opens with the same structure, whether it came from ten alarms or ten thousand:
| Section | What it shows |
|---|---|
| Origin | The most likely root-cause entity and signal, with confidence |
| Timeline | Alarms and signals in causal order, each linked to the one that triggered it |
| Impact | Affected services, tenants and endpoints, and any lost redundancy |
| Hypotheses | Ranked alternative explanations with supporting and contradicting evidence |
| Evidence | Links from every conclusion back to raw telemetry |
Review hypotheses
Hypotheses are ranked, not final. Engineers can confirm, reject or annotate each one. Rejections with a reason are recorded and inform future ranking. When evidence is incomplete, confidence is shown as such rather than hidden.
Check an action
Any proposed action — from an engineer, a script, a runbook or Raincurve itself — can be verified before it runs. The check evaluates the action against current failures and in-flight changes and returns one of three results:
| Result | Meaning |
|---|---|
| Safe | No endpoint loses resilience below its requirement |
| Not safe now | The action would cause harm given current state; the blocking condition is named |
| Out of scope | The action affects properties the check does not cover (for example routing policy); human review required |
Approve and pace
Approved fleet-wide actions are scheduled rather than pushed at once. Pacing respects a changes-per-minute cap, starts slowly while an action is unproven, and accelerates as devices succeed. Rollback is automatic if validation fails.
Post-incident reports
When an incident closes, Raincurve assembles a report: timeline, origin, impact, hypotheses considered, actions taken with their verification results, and time to resolution. Reports are exportable for customer communication and audit.