Almost no service runs alone. You depend on a cloud host, a payments provider, an email or SMS gateway, an auth provider, a CDN. When one of them has an incident, your product degrades even though nothing in your own code broke. To your customers it still looks like your outage, and your support inbox fills up with the same question: is it you, or is it something else?
Dependency monitoring is the practice of watching the providers you rely on and telling your customers, clearly, when one of them is the cause. This guide covers what to watch, how to map a provider to the part of your product it affects, and how to post a message that builds trust instead of confusion.
Why a provider's outage is your problem too
Your customers do not see your architecture. They see checkout failing, logins hanging, or emails not arriving. Whether the root cause is your database or a third party, the experience is the same, and silence reads as either you do not know or you are not saying. A short, accurate note that names the upstream provider does three things: it answers the support question before it is asked, it shows you are on top of the incident, and it sets the right expectation for when things recover.
What to monitor
Start with the providers whose outage would actually be visible to a customer. A good first list:
- Your cloud or hosting provider, and the specific 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, since a quiet failure here delays everything from receipts to alerts.
- Your CDN and DNS, which fail loudly and globally.
- Any core API your product is a thin layer over.
Most of these publish a status feed. The useful signal is not just whether the provider has declared an incident, but whether the specific part you depend on is affected, for example one cloud region rather than the whole provider.
Map each dependency to the component it affects
The link that matters is the one between a provider and the part of your own product that breaks when it is down. Map it explicitly: your Checkout component depends on your payments provider, your Login component depends on auth, your Notifications component depends on the email gateway. Keep it user-defined rather than inferred, because only you know which of your features actually rely on which provider, and an inferred guess that is wrong is worse than no guess at all.
Once the map exists, an upstream incident on a provider you depend on can automatically flag the affected component, instead of someone noticing the support tickets an hour later and updating the page by hand.
Post an honest upstream advisory
The message your customers see is the whole point. Keep it factual and attribute the cause to the provider without asserting anything you cannot verify. Something like: We are aware of an ongoing issue with a provider we rely on for payments. Some checkouts may be affected until it is resolved. We are monitoring it and will update here.
Notice what that does and does not say. It names the kind of dependency, it scopes the impact, and it promises updates. It does not claim your data is safe, it does not guess at a fix time, and it does not pretend the problem is smaller than it is. An advisory that overpromises costs you more trust than the outage itself.
How Sentivel does it
Sentivel lets you map each of your components to the providers it depends on, down to the specific part such as a single region. When a provider you have mapped has an incident, or the exact part you rely on goes unhealthy, Sentivel can automatically post a plain-English advisory on your status page that attributes the cause to the provider, and clear it when the upstream issue resolves. The dependency map you define is what drives the message.
This is not a new idea on its own. A couple of other tools will auto-flip a component when a third party is down. Where we focus is the part customers actually read: a clear, branded, honest message rather than a silent status change, driven by a dependency map you control. You can also keep it review-first if you would rather approve advisories before they post.