ServiceAlert keeps an archive of operational states reported by cloud and SaaS providers. The archive is useful for comparing reported incident patterns, but it is not a measure of every request made by every customer.
Recurring patterns
Shared dependencies increase the visible impact
Several services can report trouble at the same time because they use the same cloud, identity, network, or communications provider. Treat a cluster of notices as a reason to inspect dependencies, not proof of a common root cause.
Partial failures are common
Many notices describe one component, region, or customer group rather than a complete outage. Monitoring should preserve that scope. A simple up-or-down label can hide the distinction between a failed API, delayed background work, and a broad service interruption.
Identity and communications affect the response itself
When sign-in or team communications fail, responders may lose access to the systems used to coordinate recovery. Keep emergency access procedures and an alternate communications route outside the primary dependency.
Recovery is not always uniform
A provider may mark an incident resolved while queues drain or customer applications recover at different rates. Continue watching application telemetry after the provider's final notice.
How to use the archive
Use status observations to ask better questions:
- Which vendors reported repeated issues in the period you care about?
- Did incidents affect components your company uses?
- How clearly did the provider communicate scope and recovery?
- Does your own telemetry support the same timeline?
Avoid turning a small number of status notices into a universal reliability ranking. Provider reporting practices differ, and a status-page observation is not the same as end-to-end availability.
Current observations and publication limits are available in the reliability hub. Completed monthly summaries are available under reports, and current events are listed in incident history.