Skip to main content
Your application’s reliability is bounded by its weakest dependency. If Stripe goes down, your payments fail. If AWS S3 goes down, your file uploads break. Monitoring third-party services lets you detect these problems before your users report them.

​
Why monitor third parties?

​
Faster incident response

When your application breaks and the root cause is an upstream dependency, monitoring data tells you immediately: “Stripe is reporting degraded performance” vs spending 30 minutes debugging your own code.

​
Accurate status communication

When you know a third-party is down, you can communicate accurately to your users: “Our payment provider is experiencing issues. We’re monitoring and will update when it’s resolved.”

​
SLA evidence

If a vendor’s outage causes you to violate your own SLA, monitoring data provides evidence for credits or escalation.

​
What to monitor

​
Vendor health endpoints

Many services expose public health APIs:
ServiceHealth endpoint
AWShttps://health.aws.amazon.com
Stripehttps://status.stripe.com/api/v2/status.json
GitHubhttps://www.githubstatus.com/api/v2/status.json
Cloudflarehttps://www.cloudflarestatus.com/api/v2/status.json

​
Your integration points

Monitor the specific APIs you depend on, not just generic health:
  • Payment processing endpoint (not just Stripe’s status page)
  • Email delivery API (not just SendGrid’s homepage)
  • Storage API (not just S3’s console)

​
Status page feeds

Most vendors use Atlassian Statuspage or similar, which provides JSON APIs for component status and incidents.

​
Monitoring strategies

​
Direct endpoint monitoring

Create HTTP monitors that call the vendor’s API: 
monitors:
  - name: Stripe API
    type: HTTP
    config:
      url: https://api.stripe.com/v1/charges
      method: GET
    frequency: 60
    assertions:
      - type: StatusCodeAssertion
        config:
          expected: "401"
          operator: equals
A 401 Unauthorized response confirms the API is alive and responding (you’re not passing valid credentials, which is intentional).

​
Status Data tracking

Subscribe to vendor status feeds to get automatic incident detection and categorization:
  • Service goes to “Major Outage” → incident created
  • Service returns to “Operational” → incident resolved
  • No polling needed — the platform tracks it for you

​
Heartbeat from your integration

Have your application send a heartbeat after each successful vendor API call: 
result = stripe.charges.create(amount=1000, currency="usd")
requests.get("https://ping.devhelm.io/your-heartbeat-url")
If the heartbeat stops, either your app or the vendor has a problem.

​
Alert routing

Route third-party alerts differently from your own infrastructure alerts:
  • Third-party outages go to a #vendor-status Slack channel
  • Your infrastructure alerts go to PagerDuty on-call
  • Combine both in a unified dashboard for incident commanders

​
DevHelm Status Data

Status Data overview

Track third-party service health automatically.

Tracking dependencies

Add services to your dependency list.