HTTP Protocol / Web Server Service Unavailable

The server is currently unable to handle the request due to a temporary overload or scheduled maintenance. This is a temporary condition which will be alleviated after some delay. It indicates that the server is temporarily unable to process the request.

Common Causes

Server overload (too many requests, insufficient CPU/memory/disk resources)
Server maintenance or planned downtime
Backend service unavailability (e.g., database down, microservice unresponsive)
Application crashes or unhandled exceptions
Load balancer misconfiguration or health check failures
Resource exhaustion (e.g., file descriptors, network connections)
Firewall or network issues blocking backend communication

How to Fix

1 Verify Server Health and Resources

Check the health of the web server(s) and application servers. Monitor CPU, memory, disk I/O, and network usage to identify resource bottlenecks. Look for recent deployments or configuration changes that might have triggered the issue.

BASH

$ ssh user@your-server-ip 'uptime; free -h; df -h; top -b -n 1 | head -n 20; netstat -an | grep ESTABLISHED | wc -l'

2 Review Application and Server Logs

Examine application logs (e.g., Nginx, Apache, application-specific logs) for errors, exceptions, or warnings that coincide with the 503 errors. Look for database connection issues, unhandled exceptions, or service startup failures. Use centralized logging tools if available.

BASH

 $ tail -f /var/log/nginx/error.log
tail -f /var/log/apache2/error.log
kubectl logs -f <pod-name> -n <namespace>
journalctl -u <service-name> -f

3 Validate Load Balancer Configuration and Health Checks

Ensure that the load balancer (e.g., AWS ELB/ALB, Nginx, HAProxy, Kubernetes Ingress) is correctly configured with health checks that accurately reflect the backend service's availability. A misconfigured health check can mark healthy servers as unhealthy, leading to 503s.

BASH

 $ # Example for Nginx upstream health check
http {
    upstream backend {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
        # Nginx Plus or third-party modules for active health checks
        # For basic Nginx, ensure servers are up and listening
    }
}

# Example for AWS ALB target group health check settings (console/CLI)

4 Check Dependent Services and Databases

If your application relies on other services (databases, message queues, external APIs, microservices), ensure they are running, accessible, and performing correctly. A failure in a critical dependency can cause the main service to return 503.

BASH

 $ ping database-server-ip
curl -v http://internal-api-endpoint/health
ps aux | grep mysql # or postgres, redis, etc.

5 Scale Resources or Optimize Application

If the issue is due to overload, consider scaling up (more powerful servers) or scaling out (more instances). Optimize application code, database queries, or caching strategies to reduce resource consumption and improve performance.

BASH

 $ # Example for Kubernetes horizontal pod autoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70