Degraded Status Health Check Response

Degraded Status Response

A degraded status indicates that the service is partially operational but experiencing issues with some dependencies. This is the middle ground between fully healthy and completely down.

Response Format

{
  "status": "DEGRADED",
  "timestamp": "2024-01-15T10:30:00.000Z",
  "httpStatusCode": 429,
  "checks": {
    "database": {
      "status": "UP",
      "duration": "15ms",
      "message": "PostgreSQL responding normally"
    },
    "redis": {
      "status": "DEGRADED",
      "duration": "250ms",
      "message": "Redis latency elevated, cache hit ratio low"
    },
    "email-service": {
      "status": "DOWN",
      "duration": "5000ms",
      "message": "SMTP server connection timeout"
    }
  }
}

When to Use DEGRADED

The degraded state is appropriate when:

• Non-critical components are down (email, notifications, analytics)
• Performance is below acceptable thresholds but functional
• Fallback mechanisms are active (reading from cache instead of primary DB)
• Rate limiting is in effect due to resource constraints

HTTP 429 Mapping

Using HTTP 429 (Too Many Requests) for degraded states signals that:

• The service is alive (not 503)
• Clients should reduce load or retry with backoff
• Load balancers can optionally route traffic away

Alerting Strategy

Status	Alert Level	Action
UP	None	Normal operation
DEGRADED	Warning	Notify on-call, investigate
DOWN	Critical	Page on-call, immediate response

The degraded state prevents alert fatigue by distinguishing between "everything is broken" and "some things need attention."