Modern applications depend on external APIs for everything: payments (Stripe), email (SendGrid), maps (Google Maps), authentication (Auth0), and dozens of other services. When these APIs fail, your application fails — even if your code is perfect.
Here's how to monitor third-party APIs so you know when they're the problem, not you.
Why Monitor Third-Party APIs?
Without external API monitoring, you're flying blind:
- Users report issues — You find out from Twitter, not your dashboards
- Wasted debugging — You investigate your code when the problem is external
- Slow response — You can't mitigate what you don't know about
- Blame games — "It's not us, it's them" without evidence
What to Monitor for Each API
Core Metrics
| Metric | What It Tells You |
|---|---|
| Availability | Is the API responding at all? |
| Response Time | Is it slower than usual? |
| Error Rate | Are requests failing (4xx, 5xx)? |
| Rate Limit Headers | Are you approaching limits? |
API-Specific Monitoring
- Payment APIs (Stripe, PayPal): Test with small amounts, verify webhook delivery
- Email APIs (SendGrid, Mailgun): Check delivery rates, bounce handling
- Auth APIs (Auth0, Firebase): Verify token validation, login flows
- Database APIs (Firebase, Supabase): Check query latency, connection limits
- CDN/Storage (Cloudflare, S3): Verify file delivery, cache hit rates
Monitoring Strategies
1. Synthetic Checks
Make periodic test requests to critical APIs:
# Example: Check Stripe health
curl -s -o /dev/null -w "%{http_code}" \
https://api.stripe.com/v1/charges \
-H "Authorization: Bearer sk_test_xxx"
# Expected: 200 (or 401 if unauthorized, which means API is up)
# Alert if: timeout, 5xx, or unexpected response
2. Real Traffic Monitoring
Track actual requests and responses in your application:
// Log API calls with timing
const startTime = Date.now();
try {
const result = await stripe.charges.create({...});
logApiCall('stripe', 'charges.create', Date.now() - startTime, 'success');
} catch (error) {
logApiCall('stripe', 'charges.create', Date.now() - startTime, 'error', error.code);
throw error;
}
3. Webhook Monitoring
For APIs that send webhooks, verify they're arriving:
// Track webhook receipt
app.post('/webhooks/stripe', (req, res) => {
const received = Date.now();
const sent = req.body.created * 1000;
const delay = received - sent;
metrics.gauge('webhook.stripe.delay_ms', delay);
metrics.increment('webhook.stripe.received');
// Alert if delay > 5 minutes (webhooks backed up)
});
4. Status Page Monitoring
Monitor the vendor's status page for announcements:
- Stripe: https://status.stripe.com
- AWS: https://status.aws.amazon.com
- Google Cloud: https://status.cloud.google.com
- GitHub: https://www.githubstatus.com
Setting Up Alerts
What to Alert On
- Availability drops: API returning errors or timing out
- Latency spikes: Response time 2-3x normal
- Error rate increases: Sudden spike in 5xx responses
- Rate limit warnings: Approaching quota limits
Alert Thresholds
# Example alerting rules
stripe_api:
availability:
warning: < 99% over 5 minutes
critical: < 95% over 5 minutes
latency_p99:
warning: > 2000ms over 5 minutes
critical: > 5000ms over 5 minutes
error_rate:
warning: > 1% over 5 minutes
critical: > 5% over 5 minutes
Responding to Third-Party Outages
Immediate Response
- Verify it's them, not you: Check their status page, Twitter, DownDetector
- Check scope: Is it all requests or specific endpoints?
- Implement fallback: Switch to backup provider or cached data
- Communicate: Update your status page, notify users
Mitigation Strategies
- Circuit breaker: Stop calling failing API, return cached/default response
- Failover: Switch to backup provider (e.g., Stripe → PayPal)
- Graceful degradation: Disable non-critical features that depend on the API
- Queue requests: For non-urgent operations, queue and retry later
Circuit Breaker Example
const circuitBreaker = {
failures: 0,
lastFailure: null,
state: 'closed', // closed, open, half-open
async call(apiCall) {
if (this.state === 'open') {
if (Date.now() - this.lastFailure > 30000) {
this.state = 'half-open'; // Try again
} else {
throw new Error('Circuit breaker open');
}
}
try {
const result = await apiCall();
this.failures = 0;
this.state = 'closed';
return result;
} catch (error) {
this.failures++;
this.lastFailure = Date.now();
if (this.failures >= 5) {
this.state = 'open';
}
throw error;
}
}
};
Monitoring Your Critical Dependencies
Identify Critical APIs
Which APIs would cause user-facing issues if they went down?
- Payment processing
- Authentication
- Core data storage
- Email delivery
- SMS/notifications
Monitoring Checklist
- ☐ List all third-party APIs your app uses
- ☐ Identify critical vs non-critical dependencies
- ☐ Set up synthetic checks for critical APIs
- ☐ Log real API calls with timing and status
- ☐ Configure alerts for availability/latency
- ☐ Subscribe to vendor status pages
- ☐ Document fallback procedures
- ☐ Test circuit breakers and failover
Monitor Your External Dependencies
OpsPulse can monitor any HTTP endpoint, including third-party APIs. Know when your dependencies fail before your users tell you.
Start Free Monitoring →Common Mistakes
- Only checking status pages: They're often delayed or incomplete
- Not tracking your own API calls: You miss issues specific to your account/usage
- Alerting on every error: Transient failures are normal; alert on sustained issues
- No fallback plan: When the API fails, you have no mitigation
- Blind trust: Assuming vendor monitoring is sufficient
Summary
Monitoring third-party APIs:
- Monitor availability and latency — Synthetic checks + real traffic
- Subscribe to status pages — Early warning from vendors
- Set up meaningful alerts — Sustained issues, not transient failures
- Have a fallback plan — Circuit breakers, failover, graceful degradation
- Track everything — You need data when diagnosing issues
Your application's reliability includes your dependencies. Monitor them like they're part of your system — because they are.