Most products rely on a cloud host, a payment provider, an email or SMS gateway, an auth provider and a CDN. When one of them has an incident, your product breaks even though your own code is fine. Customers see your product failing, and support gets the same question over and over: is it you?
Dependency monitoring means watching those providers and telling customers when one of them is the cause. This guide covers what to watch, how to link each provider to the part of your product it affects, and what to post.
Why a provider's outage is your problem
Customers don't see your architecture. They see checkout failing, logins hanging or emails not arriving, and the experience is the same whatever the cause. If you say nothing, they assume you either don't know or aren't telling them. A short note naming the provider answers the support question in advance and tells people roughly what to expect.
What to monitor
Start with providers whose outage a customer would notice:
- Your cloud or hosting provider, and the region you run in.
- Payments, if a failed charge means a failed signup or checkout.
- Auth or identity, if its downtime blocks sign-in.
- Email and SMS providers, which delay everything from receipts to alerts when they fail.
- Your CDN and DNS.
- Any API your product depends on for its main feature.
Most of these publish a status feed. What you want to know is whether the specific part you use is affected, for example one cloud region, and not only whether the provider has declared an incident somewhere.
Link each provider to the component it affects
Write down which part of your product breaks when each provider is down: Checkout depends on the payment provider, Login on auth, Notifications on the email gateway. Define these links yourself. Only you know which features rely on which provider, and a wrong automatic guess is worse than none.
With the links in place, an incident at a provider you depend on can mark the affected component straight away, before anyone notices the support tickets.
What to post
Keep the advisory factual and name the provider as the cause. For example: "We're aware of an ongoing issue with a provider we rely on for payments. Some checkouts may be affected until it's resolved. We're monitoring it and will update here."
That advisory names the kind of provider, says what is affected, and commits to updates. It doesn't claim customer data is safe, guess at a fix time, or play down the problem. If an advisory promises something and is later contradicted, customers trust you less than if you had said less.
How Sentivel does it
In Sentivel you link each component to the providers it depends on, down to a specific part such as a single region. When a linked provider has an incident, or the part you rely on becomes unhealthy, Sentivel posts a plain-English notice on your status page naming the provider, and removes it when the provider resolves the incident. If you'd prefer to approve each notice first, you can switch it to review before posting.
Other tools do parts of this. Alert24 maps provider incidents onto your own components, and Atlassian Statuspage can change a third-party component's status automatically. Sentivel's focus is the advisory customers read.