Every product depends on services somebody else operates. When one fails, your users experience it as your product failing. The cheapest fifteen minutes of monitoring work most teams have not done is putting checks on their vendors.
Why vendor status pages are not enough
They lag — a status page updates when a human at the vendor decides to. They are scoped to the vendor's view, so a regional problem may never appear. And they are incentivised toward optimism. Watch them, but do not make them your detection mechanism.
What to actually check
A real endpoint, not their marketing site — many vendors run their status page on entirely different infrastructure from their API. Something cheap and safe, like a health or version endpoint. Never anything with side effects. Respect their rate limits: a check every minute is 43,200 calls a month.
Check from where you actually call them
If your application runs in one region and your monitoring in another, you can miss a routing problem that affects only your production traffic.
Do not page on vendor outages
You cannot fix your payment provider. Route vendor checks to a quiet channel. What you want is presence of information: when your own error rate spikes and you can see the payment provider check went red two minutes earlier, your diagnosis takes thirty seconds. The exception is when you have an action available, such as failing over to a secondary provider.
Correlation is the real payoff
Put your own service health alongside your five key dependencies on one screen. When a vendor goes red two minutes before your error rate climbs, you have your answer before you have opened a log.
Track it for the commercial conversation
Keep the history. Over months you accumulate your own independent record of each vendor's availability, which is useful in a contract renewal where "our monitoring recorded fourteen outages totalling six hours last quarter" carries more weight than an impression.
Design for the outage as well as detecting it
Decide in advance, per dependency: does the feature fail loudly, degrade gracefully, or queue and retry? An email provider outage should queue and retry. A payment provider outage should fail with an honest message rather than a generic error.