Customer support used to be a queue inside your own application. Now a large part of it is someone else's API. The chat widget on the marketing site, the WhatsApp thread, the Telegram bot, the CRM connector that opens a ticket: each of those hops is a cloud service you do not operate and your customer still treats as "your product."
When that hop fails, the failure mode is ugly. The app can be up. The database can be fine. The support inbox is just empty, or the widget spins, or messages accept on the client and never arrive. Internal dashboards stay green because they are watching your processes. The customer is watching the chat window.
Support is a dependency graph now
A typical omnichannel setup has more third parties than people admit in architecture reviews:
- the chat widget CDN and its JavaScript
- the vendor API that stores and routes conversations
- WhatsApp, Telegram, SMS, or email as a channel
- identity for agents (SSO)
- the CRM or helpdesk the conversation is supposed to land in
- file upload, transcription, or bot inference sitting on yet another vendor
Any one of those can degrade without taking your core product down. Chat is often the thing customers use because the product is already failing. If the support path dies at the same time, you have combined an outage with a communication blackout.
Treat the support surface as production, not as a marketing extra. It needs the same outside-in checks you would put on checkout.
What "up" means for a chat stack
A 200 on the vendor's status page is a weak definition. You care whether a visitor can load the widget, whether a message you send through the API comes back as accepted, whether the webhook into your ticket system still fires.
Minimum useful checks:
- Widget or SDK load. Fetch the script or the bootstrap endpoint from a public network. A blocked CDN or an expired cert on the widget host looks like "chat is broken" to everyone who is not already in an agent console.
- An authenticated API call that represents a real client. Create a test conversation, send a message, or read a thread you own. Prefer a dedicated test inbox so you are not paging on customer data.
- The webhook or connector into your side. If conversations never become tickets, agents will say the product is down. Check the last-received timestamp or probe the endpoint the vendor calls.
- DNS and TLS on every hostname in the widget and API. These fail independently of the chat application.
You do not need to automate a full human conversation on day one. You need the request that would have been red during the last "chat is down but the app is fine" incident.
Cloud monitoring, not just "is our app up"
Teams still organize monitoring around services they deploy. Chat vendors, identity, and channel APIs sit in a different mental bucket: "we'll notice if support complains." Support notices after customers do.
Cloud monitoring in this sense is boring and specific: scheduled checks against the SaaS APIs your customers already depend on, from more than one region, with assertions on the response you actually need. A host dashboard that scrapes your own VMs will not tell you whether you can still post a message to the conversation API from EU-West.
That is closer to how you already think about Stripe or an identity provider. Chat deserves the same treatment because it is on the critical path for recovery. During an incident, chat is how you tell people you know.
When you compare cloud monitoring tools, ignore the ones that only scrape instance metrics you already have in the host dashboard. The useful ones can probe HTTP APIs, watch certificates, and tell a regional vendor failure from your own origin failure. Chat vendors fail regionally more often than the marketing site does.
How to tell your outage from theirs
This is the operational payoff. If the widget CDN is down and your app checks are green, you should not restart your API. If your API is 500 and the chat API is fine, you should not open a vendor ticket. If both are red, you have a bigger problem (shared DNS, a common identity provider, or an actual coincidence).
Put both classes of check in the same alerting stream. Split dashboards are how on-call loses twenty minutes. The alert should say which check failed. "Support chat API 503 from two regions, app homepage still passing" is a vendor incident with a workaround: email, a banner, a phone number. "App API 500, chat API passing" is yours.
For channels like WhatsApp, the vendor's public status is a hint, not a monitor. Their page can lag. Your probe of the API you call is the record you will use in a post-incident review.
What to put on a status page
If you publish product status, chat should be a component. Customers already treat it as part of the product. A site-wide "degraded" while only the widget is down creates more tickets than a precise "live chat delayed, email still working."
Feed that component from the checks above, with a human confirming customer impact before you announce, unless the failure is unambiguous across regions. Auto-flapping "chat incident" every time a single probe times out will train people to ignore you.
During a vendor outage, say so. "Our chat provider is returning errors, we are routing support to email" is better than implying you broke messaging. Practices and SaaS buyers have seen this movie. Honesty about a dependency is cheaper than a vague green page.
Bots, files, and the extra cloud you forgot
If the widget hands the first reply to a model, that inference API is another hop. A timeout there looks like "chat is slow" even when routing works. Probe the bot endpoint with a canned prompt in a test workspace, or at least alert when the vendor's error rate on that route crosses a threshold you already see in logs.
File uploads fail in their own way: a separate bucket, a separate hostname, a size limit that started returning 413 after a policy change. You do not need to upload a 20MB PDF every minute. A tiny fixture through the same URL the widget uses is enough.
Ad blockers and corporate proxies will hide the widget for a subset of visitors. That is not an outage. Correlate: if your probe (which does not run a blocker) still loads the script, and only some browsers fail, send people to a documented allowlist rather than paging engineering. If the probe fails too, it is the CDN or the API.
A setup you can finish in an afternoon
Pick the one support path that would hurt most if it died. For most product companies that is the website widget plus the API that stores conversations.
- Create a dedicated test account or inbox.
- Write down the exact request: URL, method, auth, success body.
