Third-party API dependency monitoring dashboard showing status of external services like Stripe, Twilio and SendGrid
# website monitoring

How to Monitor Third-Party API Dependencies

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.

Why Third-Party Failures Are Often Worse Than Your Own

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:

CategoryExamples
Payment processingStripe, PayPal, Braintree, Adyen
AuthenticationAuth0, Okta, Firebase Auth
Email deliverySendGrid, Mailgun, Postmark, SES
SMS/communicationsTwilio, Vonage
Cloud infrastructureAWS, Azure, GCP
CDNCloudflare, Fastly, CloudFront
SearchAlgolia, Elasticsearch Cloud
MapsGoogle Maps, Mapbox
AnalyticsMixpanel, Segment

Monitoring Approaches

1. Subscribe to Status Pages

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.

2. Monitor Integration Endpoints Directly

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.

3. Proxy Health Checks Through Your Application

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.

4. Heartbeat Monitoring for Background Jobs

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.

Alert Strategy for Third-Party Failures

Third-party failures require a different response than your own infrastructure failures:

When a third-party is down:

  1. Confirm the failure (is it their side or yours?)
  2. Check their status page for updates
  3. Update your public status page with context: "We're aware of an issue with payment processing. This is caused by an ongoing outage at our payment provider."
  4. Communicate timeline expectations if known
  5. Implement fallbacks where possible (graceful degradation)
  6. Monitor for recovery

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.

Graceful Degradation During Third-Party Outages

Design your application to degrade gracefully when dependencies fail:

  • Payment processing down: Disable checkout, show clear message, save cart
  • Email provider down: Queue emails, retry when service recovers
  • Authentication provider down: Allow existing session users to continue; block new logins with clear messaging
  • CDN down: Serve assets directly from origin
  • Maps API down: Show text address instead of map embed

Applications that degrade gracefully — rather than throwing 500 errors — maintain user trust during incidents and simplify communication.

Building a Dependency Map

Before you can monitor dependencies, you need to know what they are. Create a dependency map:

  1. List every external API call your application makes
  2. Categorise by criticality (what breaks if this fails?)
  3. Identify the health check endpoint or method for each
  4. Set up appropriate monitors

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.

Integration with Incident Response

When your monitoring detects a third-party failure, your incident management process should kick in:

  1. Verify the failure is on the third-party's side
  2. Assess user impact
  3. Communicate via status page
  4. Monitor for recovery
  5. Post recovery: document the incident and consider mitigation (fallbacks, alternative providers)

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.

More posts

What Is Generative AI? How It Works and What It Creates

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 more
What Is Cursor AI? The AI Code Editor Explained

Cursor 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 more
What Is Claude Opus? Anthropic's Most Powerful Model Explained

Claude 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 more

Subscribe to our PRO plan.

Looking to monitor your website and domains? Join our platform and start today.