
Modern web applications are rarely standalone — they depend on a constellation of third-party APIs. Your application might be perfectly healthy while your users can't complete purchases because Stripe is down, can't log in because Auth0 is degraded, or aren't receiving emails because SendGrid has an outage.
Third-party API dependency monitoring means tracking the availability and performance of the external services your application depends on — so you know about their failures before your users do, and you can communicate accurately during incidents.
When your infrastructure fails, you control the response. You can roll back, scale up, restart services. When a third-party API fails, you're waiting for them to fix it.
The most problematic aspect: users blame you, not the third party. From a user's perspective, "my payment didn't go through" on your platform is your problem, regardless of whether Stripe was down. This makes proactive communication during third-party outages essential.
Common third-party dependencies by category:
| Category | Examples |
|---|---|
| Payment processing | Stripe, PayPal, Braintree, Adyen |
| Authentication | Auth0, Okta, Firebase Auth |
| Email delivery | SendGrid, Mailgun, Postmark, SES |
| SMS/communications | Twilio, Vonage |
| Cloud infrastructure | AWS, Azure, GCP |
| CDN | Cloudflare, Fastly, CloudFront |
| Search | Algolia, Elasticsearch Cloud |
| Maps | Google Maps, Mapbox |
| Analytics | Mixpanel, Segment |
Every major API provider publishes a public status page. Subscribe to these for email or webhook notifications when they report incidents:
Limitation: Status pages are often updated after the impact has started, and companies sometimes underreport severity. Don't rely solely on status pages.
For critical dependencies, set up HTTP monitors pointing at the endpoints your application actually calls. This tests the real path — not just whether the provider says they're up.
Examples:
# Test Stripe API availability
Monitor: https://api.stripe.com/v1/health (or a test charge endpoint)
Expected: 200 OK
# Test SendGrid availability
Monitor: https://status.sendgrid.com/api/v2/status.json
Content check: "operational"
# Test your own integration endpoint
Monitor: https://yourdomain.com/api/payment-health
Expected: 200 (returns 200 only when Stripe is reachable)
The last approach — a health endpoint in your own application that pings the third-party — is particularly powerful because it tests the actual network path from your server to theirs.
Add a dedicated health endpoint to your application that tests third-party connectivity:
// Express example
app.get('/health/dependencies', async (req, res) => {
const results = {};
// Test Stripe
try {
await stripe.balance.retrieve();
results.stripe = 'ok';
} catch (e) {
results.stripe = 'error';
}
// Test database
try {
await db.query('SELECT 1');
results.database = 'ok';
} catch (e) {
results.database = 'error';
}
const allOk = Object.values(results).every(v => v === 'ok');
res.status(allOk ? 200 : 503).json(results);
});
Monitor https://yourdomain.com/health/dependencies and you get a single endpoint that confirms all critical dependencies are reachable. This is especially useful for monitoring APIs and their upstream dependencies.
If you have background workers that process jobs using third-party APIs (sending emails, processing payments asynchronously), set up heartbeat monitoring for those workers. If a worker stops sending heartbeats, you know processing has stopped — likely due to a third-party failure or worker crash.
Third-party failures require a different response than your own infrastructure failures:
When a third-party is down:
Alert routing: Third-party failures should alert your team via Slack and email rather than immediately paging on-call via SMS — you can't fix their outage, so the urgency is lower. Your job is to communicate and monitor for recovery.
Design your application to degrade gracefully when dependencies fail:
Applications that degrade gracefully — rather than throwing 500 errors — maintain user trust during incidents and simplify communication.
Before you can monitor dependencies, you need to know what they are. Create a dependency map:
Critical path dependencies (payment, auth) deserve immediate SMS alerts and should be tested every minute. Supporting dependencies (analytics, non-critical enrichment) can be checked every 5 minutes with email-only alerts.
When your monitoring detects a third-party failure, your incident management process should kick in:
Third-party dependencies are a risk that can be managed but never eliminated. Monitoring, communication, and graceful degradation are your tools for minimising their impact on your users.
Monitor your application's third-party API dependencies alongside your own uptime at Domain Monitor.
Generative AI creates new content — text, images, code, and more. This guide explains how it works, what tools are available, and where it's genuinely useful versus overhyped.
Read moreCursor AI is an AI-powered code editor built on VS Code. Learn what it does, how it works, and whether it's the right tool for your development workflow.
Read moreClaude Opus is Anthropic's most capable AI model, built for complex reasoning and demanding tasks. Learn what it does, how it compares, and when to use it.
Read moreLooking to monitor your website and domains? Join our platform and start today.