Your code is solid. Your servers are healthy. Your database is humming.
Then Stripe goes down for 20 minutes, and your entire checkout flow breaks.
Or Cloudflare has a hiccup, and your CDN-cached assets vanish.
Or AWS S3 experiences "elevated error rates," and your image uploads fail silently.
Welcome to the reality of modern web applications: your uptime is only as good as your weakest third-party dependency.
The average web application depends on 10-30 external services. Payment processors. Authentication providers. CDNs. Email delivery. Analytics. Search. Storage. Each one is a potential failure point you don't control.
You can't prevent these outages. But you can detect them instantly — before your customers do.
In this guide, we'll cover why third-party monitoring matters, which dependencies to watch, and how to build a monitoring strategy for services you don't own.
The Third-Party Dependency Problem
Modern applications are assembled, not built from scratch.
Instead of writing your own payment processing, you use Stripe. Instead of running your own email servers, you use SendGrid. Instead of building authentication from scratch, you use Auth0 or Clerk.
This is smart engineering. These services are better at their specialty than you could ever be with limited resources.
But it creates a hidden vulnerability: your application inherits the reliability of every service it depends on.
The math is brutal
If your application depends on 10 services, and each has 99.9% uptime individually:
- Single service uptime: 99.9% (8.76 hours downtime/year)
- Combined uptime (10 services): 99.9%^10 = 99.0% (87.6 hours downtime/year)
That's 10x more potential downtime — and this assumes failures are independent (they're often not).
The more third-party services you use, the more exposed you are to outages you can't prevent.
You inherit their incidents
When you choose Stripe for payments, you're choosing to share fate with every Stripe incident. When AWS has a bad day, so do you — along with half the internet.
These aren't hypothetical risks. Major third-party outages happen monthly:
- Cloudflare (June 2022): 19-minute outage affecting millions of sites
- AWS us-east-1 (December 2021): Multi-hour outage cascading to countless apps
- Fastly (June 2021): Global CDN failure taking down major news sites, Reddit, Twitch
- Stripe (multiple): Payment processing degradation affecting e-commerce globally
- Twilio (July 2022): SMS delivery failures affecting two-factor authentication
- GitHub (multiple): Outages affecting CI/CD pipelines and deployments
Your monitoring dashboard might show your servers healthy. But if Stripe is down, your customers can't pay. That's an outage — you just can't see it.
Why Internal Monitoring Isn't Enough
Traditional monitoring focuses on what you control:
- Is your server responding?
- Is your database connected?
- Is your application returning 200 OK?
This misses the third-party layer entirely.
The blind spot
Your health check endpoint might return success because your application code executed. But that doesn't tell you:
- Can users actually complete checkout? (Stripe)
- Are authentication requests succeeding? (Auth0/Okta)
- Are images and assets loading? (CDN)
- Are transactional emails being delivered? (SendGrid)
- Are push notifications going out? (Firebase/OneSignal)
Internal monitoring sees your code working. It doesn't see whether the external services your code depends on are working.
Error messages arrive late
When third-party services fail, you typically learn about it through:
- Customer complaints ("I can't checkout")
- Support tickets ("My login isn't working")
- Social media ("Is anyone else having issues with...?")
- Checking the service's status page (if you remember to)
By then, you've already lost transactions, frustrated users, and damaged trust.
Status pages lag reality
Third-party status pages are helpful but slow:
- They update after internal investigation (5-15 minutes minimum)
- They often understate severity ("minor degradation" during major outages)
- They don't tell you if the problem affects your specific integration
You need faster, more reliable detection.
Which Third-Party Services to Monitor
Not all dependencies are equal. Prioritize monitoring based on:
- User impact: Does failure block core user actions?
- Revenue impact: Does failure prevent transactions?
- Frequency of use: Is this called on every request or occasionally?
- Fallback availability: Do you have alternatives if it fails?
Tier 1: Critical (monitor immediately)
These failures directly break core functionality:
| Service Type | Examples | Impact of Failure |
|---|---|---|
| Payment processing | Stripe, PayPal, Braintree, Square | Can't accept money |
| Authentication | Auth0, Okta, Clerk, Firebase Auth | Users can't log in |
| Primary database | MongoDB Atlas, PlanetScale, Supabase | Application unusable |
| Core CDN | Cloudflare, CloudFront, Fastly | Assets don't load |
| Primary cloud provider | AWS, GCP, Azure regional | Everything fails |
Tier 2: Important (monitor proactively)
These failures degrade experience or break secondary features:
| Service Type | Examples | Impact of Failure |
|---|---|---|
| Transactional email | SendGrid, Postmark, Mailgun | No receipts, verification emails |
| SMS/2FA | Twilio, Vonage, MessageBird | 2FA fails, password resets blocked |
| Search | Algolia, Elasticsearch Cloud, Typesense | Search broken |
| File storage | S3, Cloudinary, Uploadcare | Uploads fail, media missing |
| Push notifications | Firebase, OneSignal, Pusher | Real-time features break |
Tier 3: Nice to have (monitor if easy)
Failures are annoying but not critical:
| Service Type | Examples | Impact of Failure |
|---|---|---|
| Analytics | Google Analytics, Mixpanel, Amplitude | Tracking gaps |
| Error tracking | Sentry, Bugsnag, Rollbar | Visibility gaps (ironic) |
| Feature flags | LaunchDarkly, Split | Features might misbehave |
| Chat/Support | Intercom, Zendesk widget | Support widget missing |
Focus your monitoring energy on Tier 1 and Tier 2. Tier 3 failures are survivable.
How to Monitor Third-Party Dependencies
There are several approaches, each with tradeoffs:
1. Monitor the service's public endpoints
The simplest approach: treat third-party services like any website you're monitoring.
What to monitor:
- API health check endpoints (many services expose these)
- Public status page endpoints
- The service's main website (if their site is down, their API probably is too)
Examples:
- Stripe:
https://status.stripe.com - AWS:
https://status.aws.amazon.com - Cloudflare:
https://www.cloudflarestatus.com - SendGrid:
https://status.sendgrid.com
Pros:
- Easy to set up
- No integration required
- Works with any monitoring tool
Cons:
- Status pages update slowly
- Doesn't test your specific integration
- May miss regional or partial outages
2. Monitor your own integration endpoints
Create dedicated endpoints in your application that test third-party connectivity:
GET /health/stripe
→ Makes a test API call to Stripe
→ Returns success or failure
GET /health/sendgrid
→ Verifies SendGrid API key is valid
→ Returns success or failure
GET /health/s3
→ Lists a test bucket or checks credentials
→ Returns success or failure
Pros:
- Tests your actual integration
- Catches configuration issues (expired API keys, etc.)
- More accurate than status page monitoring
Cons:
- Requires code changes
- May incur API costs for test calls
- Can trigger rate limits if checked too frequently
3. Synthetic transaction monitoring
For critical paths, create monitors that simulate complete user flows:
Example: Monitor the checkout flow
- Add test product to cart
- Initiate checkout (without completing payment)
- Verify Stripe.js loads and initializes
- Confirm session creates successfully
This tests the full integration, not just whether the third-party API responds.
Pros:
- Tests real user experience
- Catches integration bugs, not just availability
- Most accurate detection
Cons:
- Complex to set up
- May require test accounts or sandbox environments
- Higher maintenance burden
4. Monitor third-party directly with uptime checks
Add the third-party service's key URLs to your monitoring tool as separate monitors:
| Monitor Name | URL | Check Interval |
|---|---|---|
| Stripe Status | https://status.stripe.com | 5 min |
| Cloudflare Status | https://www.cloudflarestatus.com | 5 min |
| AWS Health | https://health.aws.amazon.com | 5 min |
| SendGrid API | https://api.sendgrid.com/v3 | 5 min |
This gives you parallel visibility alongside your own application monitoring.
Building Your Third-Party Monitoring Strategy
Here's a practical framework:
Step 1: Inventory your dependencies
List every third-party service your application uses. Include:
- Service name
- What it's used for
- How critical it is (Tier 1/2/3)
- Their status page URL
- Any health check endpoints
Most teams are surprised by how long this list gets.
Step 2: Set up status page monitoring
For every Tier 1 and Tier 2 dependency:
- Find their status page URL
- Add it as a monitor
- Set reasonable check intervals (5 minutes is usually fine)
- Configure alerts to a separate channel (so you can distinguish third-party issues)
This takes 15 minutes and gives immediate visibility.
Step 3: Create health check endpoints
For your most critical integrations (payment, auth), build internal health check endpoints:
- Keep them lightweight (don't make expensive API calls)
- Check connectivity, not functionality
- Return meaningful status codes and messages
- Monitor these endpoints alongside your main application
Step 4: Establish incident response for third-party outages
When a third-party service fails, your playbook should include:
- Verify it's them, not you: Check their status page and your logs
- Communicate proactively: Tell customers before they complain
- Enable workarounds if available: Switch to backup provider, disable affected features gracefully
- Monitor for recovery: Watch for their "resolved" update
- Document for postmortem: Note timeline and impact for future reference
Step 5: Plan for redundancy (where possible)
For truly critical services, consider:
- Multi-provider payment: Stripe + PayPal + direct bank integration
- Multi-CDN: Cloudflare + Fastly with DNS failover
- Email redundancy: SendGrid + Postmark with automatic failover
- Auth fallback: Social login + email/password as backup
This is expensive and complex, so reserve it for Tier 1 dependencies that justify the investment.
Alert Configuration for Third-Party Monitoring
Third-party monitoring requires different alerting than your own services:
Separate channels
Route third-party alerts to a distinct channel or notification group:
#alerts-infrastructure→ Your servers and databases#alerts-third-party→ External service issues
This helps with triage. When Stripe is down, you can't fix it — you can only wait and communicate.
Different severity thresholds
Third-party status pages often show "degraded" before "major outage." Consider:
- Status page unreachable: Warning (might be their status page, not their service)
- Status page shows "investigating": Alert your team
- Your health check endpoint fails: Critical alert
- Your synthetic transaction fails: Critical alert
Avoid alert storms
If Stripe goes down, don't send 50 alerts because 50 checkout attempts failed. Configure:
- Deduplication: One alert per incident, not per failure
- Cooldown periods: Don't re-alert for the same issue within 30 minutes
- Grouping: Aggregate related third-party failures
The Third-Party Monitoring Checklist
Use this to evaluate your current coverage:
Inventory
- You have a documented list of all third-party dependencies
- Dependencies are categorized by criticality (Tier 1/2/3)
- You know the status page URL for each service
Monitoring
- Tier 1 dependencies have their status pages monitored
- Critical integrations (payment, auth) have dedicated health checks
- Third-party monitors are separate from internal monitors
- Check intervals are appropriate (not too frequent, not too slow)
Alerting
- Third-party alerts go to a distinct channel
- Alerts identify which third-party service is affected
- You have runbooks for major third-party outages
- Alert deduplication prevents notification storms
Response
- Your incident response plan covers third-party failures
- You have customer communication templates for external outages
- Critical paths have fallback options documented
- You track third-party incidents in your postmortem process
Common Third-Party Monitoring Mistakes
Avoid these pitfalls:
Monitoring only the API, not the status page
API health endpoints can return 200 OK while the service is experiencing issues with specific features. Monitor both the API and their public status.
Checking too frequently
Third-party status pages don't update by the second. Checking every 30 seconds wastes resources and might get you rate-limited. Every 5 minutes is usually sufficient.
Not monitoring CDN from multiple regions
Your CDN might be failing in Asia while working fine in the US. Use multi-region monitoring to catch regional CDN issues.
Forgetting about API keys and credentials
Third-party integrations can fail because your API key expired, your account was suspended, or your credit card on file failed. Your health checks should detect authentication failures.
Assuming "it's not us" means "do nothing"
When a third-party fails, you still need to:
- Communicate with customers
- Log the incident
- Consider workarounds
- Monitor for recovery
"It's their fault" doesn't mean your customers aren't affected.
How Webalert Helps Monitor Third-Party Services
Webalert makes third-party dependency monitoring straightforward:
Check the full feature set and compare plans and pricing.
Monitor any URL
Add your critical third-party status pages as monitors. Stripe, AWS, Cloudflare, SendGrid — any public URL can be tracked.
Multi-region visibility
Third-party services can fail regionally. Webalert's global checks detect issues that might only affect specific geographic areas.
Flexible alerting
Route third-party monitors to separate notification channels. Get SMS for payment processor issues, email for analytics outages.
Response time tracking
Slow third-party services impact your user experience. Track response times to catch degradation before it becomes an outage.
Simple setup
No complex integration required. If it has a URL, you can monitor it in seconds.
Final Thoughts
Your application's reliability is a team effort — and most of that team are third-party services you don't control.
Every payment processor, every CDN, every authentication provider is a potential failure point. When they go down, you go down. When they're slow, you're slow. Their incident becomes your incident.
You can't prevent these failures. AWS will have outages. Stripe will have degradation. Cloudflare will have bad days.
But you can detect them instantly:
- Monitor third-party status pages and health endpoints
- Build internal health checks for critical integrations
- Configure alerting that distinguishes external from internal issues
- Prepare response plans for services you can't fix
The companies that handle third-party outages well aren't lucky — they're prepared. They know which services they depend on, they monitor those services actively, and they have playbooks ready for when things break.
Because in the modern web, your uptime is everyone's uptime.
And you should know the moment any of it fails.
Ready to monitor what you don't control?
Start monitoring third-party dependencies free with Webalert →
Explore features or see pricing.
Monitor any URL. Get instant alerts. Know before your customers do.