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 a Subdomain Takeover and How to Prevent It

A subdomain takeover lets an attacker claim your subdomain by exploiting dangling DNS records. Learn how it happens, real-world examples, and how DNS monitoring detects it.

Read more
What Is Mean Time to Detect (MTTD)?

Mean time to detect (MTTD) measures how long it takes to discover an incident after it starts. Reducing MTTD is one of the highest-leverage improvements in reliability engineering.

Read more
What Is Black Box Monitoring?

Black box monitoring tests your systems from the outside, the way users experience them — without access to internal code or infrastructure. Learn how it works 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.