Which dependencies should you monitor?

Monitor the external operations your product depends on, then decide which failures require a person to act. Set the priority by the operation, its users and the fallback available. A vendor category alone cannot tell you how urgently to respond.

Start with one important user journey. Map its vendor connections, identify the evidence you can inspect, and write down who owns the response. Expand that record as you review the rest of the application.

Inventory the connections your code actually uses

Dependency files can identify likely API clients. They will not necessarily reveal a custom HTTP call, a runtime-selected endpoint or a service reached through another service. Follow the dependency-file review to connect a package to its actual operation and environment.

For each confirmed connection, record:

• The product feature or internal job that calls it.
• The configured vendor product, endpoint and region, where relevant.
• The team responsible for that integration.
• The logs, request metrics or job records that show whether it is working.
• The behavior users see when it fails.

Avoid assigning urgency by vendor name alone. Email might carry an optional receipt or a required sign-in link. Error reporting may not stop a transaction, but losing it can remove evidence you need during another incident.

Separate a page from an informational update

An immediate page needs an immediate action. A team-channel update can provide useful context without interrupting the on-call engineer. A review item can wait until someone is available to investigate it.

Google's SRE monitoring guidance (opens in new tab) recommends actionable paging tied to symptoms. Apply that distinction to your user journeys: what is failing, how urgent is the consequence, and what can the recipient do?

A vendor's severity label is one input. It cannot tell you whether the affected product or region matches your integration. Conversely, a small vendor incident can matter greatly if it affects an operation your product cannot complete without.

Choose thresholds from the failure you need to catch

Look at successful outcomes, errors, duration and outstanding work for the relevant operation. Include traffic volume: no observed errors may simply mean that no requests were made.

Choose a threshold and evaluation period based on the affected work, the user’s deadline and the cost of interrupting someone. A short failure can still prevent an operation from completing; a fixed waiting period will not suit every task.

Review the rule after real incidents and planned exercises. Record missed failures and notifications that required no action. Change the rule from that evidence; do not assume that lowering notification volume has improved coverage.

Put the response beside the alert

A short runbook should let another engineer continue the investigation:

1. Inspect the failing operation. Compare internal changes, application evidence and relevant vendor reports. Correlation alone does not establish the cause.
2. Check the next safe action. Use tested retry, cancellation and fallback behavior. A timeout does not prove that a payment or other state-changing request never completed.
3. Communicate the known impact. Name the affected feature and what users should expect. Keep unconfirmed causes out of the update.
4. Verify recovery. Check completed operations and remaining backlog, then decide when to return to normal behavior.

The checkout investigation guide gives a more specific example of protecting state while diagnosing a failure.

Connect the inventory to ongoing monitoring

In CheckUpstream, create an account, connect GitHub or GitLab, and select a public or private repository. That connection starts a scan. Review the detected vendor matches against production usage and check your alert settings.

In Settings → Alerts, configure an available destination and send a test. Every enabled destination receives vendor incident and SDK failure alerts, whatever severity the vendor reports. Channel availability depends on your plan; the alert guide explains the supported setup. The response priorities above are a team runbook, not built-in per-tier alert controls.

Revisit the inventory when integrations or deployment configuration change. Update the owner, request dashboard and response steps for each affected operation.

Correction, September 11, 2026: removed an unsourced incident story, fixed paging delays, blanket vendor-priority rules and unsupported automatic monitoring claims.