What support should do when a vendor is down
Private dashboard on Pro.
When checkout fails or login hangs, customers write to support first. If the cause is a vendor, the worst answer is "we are looking into it" for forty minutes while engineering rediscovers a status page post. A short playbook lets agents respond in the first reply.
The first two minutes
- Open the vendor board, or the Slack channel that receives vendor alerts.
- Match the symptom to a component. Failed webhooks and a "Stripe: Webhooks degraded" row are the same incident. A generic 500 with every vendor green is probably yours.
- If a vendor row is not operational, say so in the ticket. Name the vendor and the component. Link the official status page.
- Do not guess at a time to fix. Vendors rarely publish one. Say you are watching their updates.
That is the whole first pass. Most tickets in a vendor incident are the same ticket with different account numbers.
What to tell the customer
Keep it specific and calm.
- "Checkout is failing because our payment provider is reporting a problem with webhooks. Their status page is here. We will write when they mark it resolved or we have a workaround."
- "Sign-in is slow because our authentication vendor posted a degraded API. Existing sessions should keep working."
- "We do not see a vendor incident that matches this. I have passed it to engineering."
Do not blame the vendor by nickname, and do not paste internal Slack. The official status page is the public source.
When to escalate
Escalate to engineering when:
- The vendor board is green and the customer still fails
- The vendor lists a component you do not follow, and you are not sure it is relevant
- You need a workaround (queue jobs, switch a backup provider, disable a feature) rather than a status sentence
Do not escalate every new ticket during a known vendor incident. A single engineering thread plus a saved reply is enough.
After it is over
When the vendor returns to operational, send one follow-up on the open tickets: the incident is marked resolved, here is what to retry, here is how to write if it is still broken. Then close the duplicates.
If the same vendor burns you twice in a quarter, add a note to the playbook: who owns the relationship, whether you have a backup, and whether support should offer a manual process.
Make the playbook easy to find
Put the vendor board link at the top of the support handbook. Put Slack alerts in a channel agents already watch, not a channel only engineers joined. On Pro, Outage Clock's private page is meant for this: no extra login, no extra noise.
Questions
Should support follow vendors themselves?
One shared list is better. If every agent follows a private copy, filters drift and the board disagrees with itself.
What if the vendor has not posted yet?
Say you cannot confirm a vendor incident yet, and that you have flagged it internally. A reachability check that fails is a hint, not a quote. Wait for the official page before you name the vendor in a public reply.