Guide

Understand the data

Use each source to answer a different question. A vendor incident and an application failure are separate observations.

Projects and vendor matches

A project represents an application or repository. A service is an external vendor or product, such as Stripe or AWS S3. A dependency connects your project to a service.

Repository scans suggest those connections from supported dependency files. Review the matches: a package might only run in development, and a custom API call might not appear in a manifest at all.

An organization groups your projects, team and settings. SDK keys belong to a project; API tokens grant scoped access to the organization. See Credentials & Security before adding either to an integration.

Vendor status and incidents

A vendor's status page describes the conditions it has reported. An incident record brings together its updates and available start and resolution times.

Check the source and observation time when investigating. Missing updates or a missing resolution time do not establish that a vendor is currently down. Vendor reports may cover products or regions your app does not use.

The status directory shows source context. The methodology explains how public reliability data is collected and qualified.

Application telemetry

The optional SDK measures supported outbound HTTP calls from your application. Request duration, status codes and failures help you check whether a vendor issue coincided with problems in your app.

These measurements cover the requests your instrumentation captures. A quiet chart can mean no traffic or missing instrumentation; it is not proof that every request succeeded. A slow response is different from an error, and neither alone identifies the root cause.

See the SDK Reference for available runtimes, configuration and event fields.

Alerts and investigation

Alerts notify your team about selected vendor incidents. A connection in the dependency map helps identify projects to investigate; it does not confirm customer impact.

Compare the vendor's affected products and timeline with your own requests, logs and deployment history. Keep the vendor report and your observations separate in the postmortem template.

Vendor incident counts

Where CheckUpstream counts a vendor's incidents, it shows two numbers from the vendor's own status page: incidents the vendor reported as starting in the last 90 days, and incidents the vendor has not yet marked resolved. Records the vendor labels as having no impact are left out.

A project's Incident history tab lists the first count for each matched vendor, and a pull request check lists both for the vendors a changed dependency maps to. A pull request check never fails; it is neutral while a matched vendor reports an open incident.

A count is the vendor's claim. It does not show whether your application was affected, and CheckUpstream does not combine counts into a score or a ranking of vendors. Compare the vendor's timeline with your own requests and logs before drawing a conclusion. The methodology explains what each source can establish and where coverage is limited.

SLA terms

Vendor downtime and your application's failures are different from contractual SLA eligibility. A claim depends on the vendor's covered product, plan, measurement window, exclusions and submission deadline.

Use the SLA guides to find a vendor's published terms. CheckUpstream does not assess eligibility, estimate credits or prepare claims; it keeps the vendor's own incident timeline and the checks we record.