External API Health Check Component Design

External API Health Check

External API checks verify that third-party services your application depends on are reachable. These checks require careful design to avoid cascading failures.

Response Component

{
  "external-api": {
    "status": "UP",
    "duration": "145ms",
    "message": "Payment gateway responding",
    "details": {
      "endpoint": "api.stripe.com",
      "lastSuccessful": "2024-01-15T10:29:55Z",
      "circuitBreaker": "closed"
    }
  }
}

What to Check

1. Reachability: Can you connect to the API endpoint?
2. Response time: Is latency within acceptable bounds?
3. Authentication: Are API keys / tokens still valid?
4. Rate limits: Are you approaching rate limit thresholds?
5. Circuit breaker state: Is the circuit open, half-open, or closed?

Circuit Breaker Integration

{
  "payment-gateway": {
    "status": "DEGRADED",
    "message": "Circuit breaker OPEN - using cached responses",
    "details": {
      "circuitBreaker": "open",
      "failureCount": 5,
      "lastFailure": "2024-01-15T10:28:00Z",
      "nextRetry": "2024-01-15T10:30:00Z"
    }
  }
}

Best Practices

Practice	Reason
Set short timeouts (2-3s)	Don't let slow APIs block health checks
Use circuit breakers	Prevent cascading failures
Cache last-known status	Avoid hammering failing APIs
Check health endpoints first	Don't hit production endpoints
Consider non-critical vs critical	Route only critical to DOWN

Timeout Strategy

External API checks should have shorter timeouts than your health check endpoint timeout. If your readiness probe timeout is 5 seconds, external API checks should timeout at 2-3 seconds to leave margin for response assembly.