Deciding when a vendor incident should page someone

A vendor incident deserves attention when it creates a problem your team needs to act on. The vendor name alone does not determine the urgency. Start with the part of your product that depends on it.

Write the response rule before an incident

For each dependency, record the user journey it supports, the evidence that would confirm a failure, and the person responsible for the response. Decide what requires an immediate page and what can be reviewed during working hours.

An optional summarisation feature and a payment authorisation step may need different responses. That decision depends on your product commitments and tested fallbacks. A vendor’s severity label cannot make it for you.

Verify that the fallback works

A fallback needs its own checks. Confirm that it returns an appropriate result, that users understand any limitation, and that someone will notice if it also fails. Record how you will return to normal operation.

An upstream notification is context for the investigation. Check your application data before dismissing an incident or telling colleagues that no action is needed.

Review the alerts your team actually receives

After an incident, ask whether the notification named a relevant dependency and project, arrived through the right channel, and led to an action. Change noisy rules based on that record. Track alert volume and useful responses before claiming that monitoring has reduced pages.

Use the alert setup guide to check your destination, then send a test. Incident alerts go to every enabled destination whatever the vendor’s severity label, so your response rule decides who acts. Confirm who will receive the message and what they should do with it.

Correction, September 6, 2026: removed an unsubstantiated customer story and results. This is a response-planning guide.