Guide
Understand the data
Use each source to answer a different question. A vendor incident and an application failure are separate observations.
- Which projects use this vendor?
- Repository matches
- Confirm the package runs in production.
- What has the vendor reported?
- Status records and incidents
- Check the affected product, region and update time.
- Did our requests fail?
- Application telemetry and logs
- Check traffic coverage and the incident timeline.
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.
Reliability scores
The dependency risk score combines available history into a value from 0 to 100, with higher values indicating more risk in those inputs. It is computed on demand.
How the risk score is weighted
| Signal | Weight |
|---|---|
| Incident-based uptime deficit over 30 days | 40% |
| Request-weighted community error rate over 7 days | 25% |
| Incident frequency over 90 days | 20% |
| Average resolution time in the available incident window | 10% |
| No configured status page | 5% |
The score is a comparison aid, not a forecast or a measure of your app's availability. A low score can also reflect missing incident or request data. Review the underlying evidence before choosing or replacing a vendor. The methodology explains observation limits and how incident severity affects downtime summaries.
SLA evidence
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 the relevant terms and evidence to collect. CheckUpstream does not establish eligibility from a vendor incident alone.
Put the sources together
Connect your repository and review its vendor matches.