The burden of proof is yours
Every provider agreement puts the evidentiary burden on the customer. You assert the breach, you supply the timeline, you show the impact on your resources specifically. The provider's reviewer starts from their own telemetry, which was built to measure their definition of availability, not your experience of it. Your job is to make the gap undeniable.
The status page is not your witness
The reflex during an incident is to check the provider's status page. As evidence, it is close to worthless, and often it is testimony for the other side. Status pages famously lag and understate: an incident can degrade your workloads for the better part of an hour while the dashboard reports "operational." History backs this up. In the April 2011 EC2 outage documented by No Jitter, disruption "continued into the next day" beyond the initially contained incident. If your only record is the provider's public messaging, your claim inherits its understatement.
What to capture, and when
Strong claims are assembled during the incident, not reconstructed weeks later when log retention has already eaten the raw material. The timeline below marks the capture points that matter:
First failed request
Alert fires from your own monitoring. Record the first failure timestamp in UTC, not "around 2am."
capture: start time · alerting screenshotScope identified
Which services, regions, and resources are affected. Names and IDs, not descriptions.
capture: service + region + resource IDsProvider-side cause confirmed
Error samples and request IDs showing failures originate in the provider's infrastructure, not your code. This is the exhibit that defeats the "customer misconfiguration" exclusion.
capture: request IDs · error responses · graphsLast failed request
The end timestamp. The interval between first and last failure is your downtime figure, the number the whole claim rests on.
capture: end time · recovery graphClaim file assembled
Uptime math computed against the SLA commitment, billing line items for the affected service attached, claim window countdown calendared.
capture: uptime calc · invoice lines · deadlineThe claim file, item by item
Make it a habit, not a heroic effort
None of this is hard on the day. All of it is impossible three weeks later: metrics roll off, dashboards change, and the engineer who saw the errors has moved on. The teams that recover credits consistently treat evidence capture as a standard incident-response step, one more checklist item alongside the postmortem. One incident folder, one ledger row per event, and the claim in part 6 becomes an afternoon's work.
Key takeaways
- The evidentiary burden is on you. The provider's telemetry defends the provider.
- Status pages lag and understate. Independent monitoring is the only reliable witness.
- Capture during the incident: UTC timestamps, resource IDs, request IDs, exported graphs.
- Request IDs proving provider-side failure defeat the most common rejection ("your misconfiguration").
- Evidence capture belongs in the incident checklist, next to the postmortem, not as a later project.