Alert on impact, not existence

A vendor incident gives your team a lead. A useful alert also names the relevant project, explains what is known, and points to something a person can check or do.

That distinction matters when the same provider supports several parts of your application. A failure in an optional background task and a failure during sign-in may deserve different responses, even when the vendor gives both the same severity.

Name the operation you need to protect

Start with the repositories and services your team owns. CheckUpstream scans supported dependency files and matches known packages to vendors. Review those matches: a package can be unused, limited to development, or configured to call a different host.

The scan does not establish every model, region or operation your application uses. Follow each important match into the code and deployed configuration. Keep a link to the relevant request dashboard or runbook. The dependency review guide shows what to record.

Say what the evidence establishes

Keep three observations separate:

• Vendor report: the product, region and period the vendor says were affected.
• Endpoint measurement: what a particular probe observed under its configured check.
• Application evidence: what happened to the requests or jobs your customers rely on.

One can support an investigation without proving the others. A green status page does not rule out an application failure. A failed probe does not establish that every customer account is affected. Missing request data is unknown, not a healthy result.

Check the source and observation time attached to a record. The measurement methodology explains how to read the available checks and their limits.

Make routing a deliberate policy

Decide which conditions need a page, which belong in a team channel, and which can wait for review. Google's SRE monitoring guidance (opens in new tab) connects paging to urgent, actionable symptoms. Use your product's commitments and failure behavior to make that decision.

CheckUpstream sends an alert in two cases. The first is when the vendor declares an active incident, outside scheduled maintenance, on a service you depend on. When that service covers only some components of a shared status page, an incident that names only other components is not sent. The alert shows the vendor's severity label, but the label never decides whether it is sent. The second is when your own SDK's calls to that vendor fail above the threshold printed in the alert. Those counts include server errors, network errors and timeouts, but not 4xx responses. Choose an enabled channel, then send a test using the alert setup guide.

Neither case depends on usage detail, such as which operations or regions you call, so missing detail does not silence an alert. Maintenance windows, opt-outs and undeliverable addresses still apply, and each suppressed alert is recorded with its reason.

When a notification arrives, inspect the relevant application requests before deciding how to respond. Receiving no alert does not establish that those requests succeeded.

Finish with an owner and a next step

For each important dependency, keep a short response note:

• Where to inspect the affected operation and its recent changes.
• Who owns the response and how to reach them.
• Which fallback or degraded behavior has been tested.
• What evidence establishes recovery, including queued work.

During an incident, state what is confirmed and what remains uncertain. Update that record as the investigation changes instead of treating the first vendor notification as a diagnosis.

Correction, September 11, 2026: removed unsupported customer-impact figures, detection comparisons and guarantees about alert suppression and credits.