Getting a 503 Service Temporarily Unavailable error in Kubernetes and Linux usually means the request successfully reached Nginx, but the backend application is currently unavailable, overloaded, or marked unhealthy.

In Kubernetes, this often happens because:

• Readiness probes are failing.
• Pods become unhealthy.
• Services lose healthy endpoints.
• Applications respond too slowly due to CPU or memory pressure.

In Linux environments, common causes are:

• Overloaded Application.
• Nginx Rate limit configuration.
• Backend services being unavailable.

This guide focuses on fast troubleshooting of 503 Service Temporarily Unavailable errors, followed by deeper root-cause analysis for both Kubernetes and Linux environments.

How to Fix 503 Service Temporarily Unavailable in Kubernetes

If you are troubleshooting a production issue, check these first before touching ingress rules or networking.

In most cases, the issue is:

• Pod not ready.
• No healthy endpoints.
• Readiness probe failing.
• Application too slow under load.

Follow the below steps in order.

Step 1: Check Service Endpoints

Run:

# kubectl get endpoints -n <namespace>

If the output shows:

<none>

Your Service currently has no healthy pods available to receive traffic.

Since Ingress has nowhere to send the request, it may return a 503 Service Temporarily Unavailable error.

Step 2: Check Pod Status

Run:

# kubectl get pods -n <namespace>

Look carefully at the READY, STATUS, and RESTARTS columns.

Common unhealthy states include:

0/1 READY
CrashLoopBackOff
OOMKilled
Error

If you see:

0/1 READY

The pod is running, but Kubernetes is not allowing traffic to it.

This is usually caused by failed readiness probes, which means the pod is considered unhealthy and is removed from the Service endpoints.

Step 3: Check Pod Events

Run:

# kubectl describe pod <pod-name> -n <namespace>

Look for common errors such as:

Readiness probe failed
OOMKilled
Back-off restarting failed container

These events often point directly to the root cause of the issue and can save a lot of troubleshooting time.

Step 4: Check Readiness Probe Configuration

One of the most common Kubernetes causes of a 503 Service Temporarily Unavailable error is a failed readiness probe.

Run:

# kubectl describe pod <pod-name> -n <namespace>

If you see “Readiness probe failed”, Kubernetes marks the pod as unhealthy and removes it from the Service endpoints.

Problem 1: Wrong Health Path

Incorrect example:

readinessProbe:
  httpGet:
    path: /
    port: 5000

Sometimes / becomes slow because:

• Database calls happen.
• Application performs heavy processing.
• Backend slows down under high traffic.

A better approach is to use a lightweight /health endpoint for readiness checks.

readinessProbe:
  httpGet:
    path: /health
    port: 5000

Problem 2: Application Is Too Slow, and timeoutSeconds Too Low

By default, Kubernetes waits only “1 second” for a readiness probe response. Under high load, 1 second can be too short.

readinessProbe:
  httpGet:
    path: /health
    port: 5000
  timeoutSeconds: 5

Here, Kubernetes waits up to 5 seconds for the readiness response before marking the pod unhealthy.

This commonly fixes readiness failures during:

• High CPU usage.
• Traffic spikes.
• Slow application startup.

Step 5: Check CPU and Memory Usage

Run:

# kubectl top pod -n <namespace>

# kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Look for errors such as:

no healthy upstream
upstream timed out

If You See “no healthy upstream”

This usually means:

• Service has no healthy endpoints.
• Readiness probes are failing.
• Pods became NotReady.

Possible fixes:

• Check readiness probe configuration.
• Verify Service selectors and labels.
• Verify pod health.

If You See “upstream timed out”

This Usually means:

• Application is responding too slowly.
• CPU usage is high.
• Backend is overloaded.

Possible fixes:

• Increase timeoutSeconds in readiness probes.
• Increase CPU limits.
• Scale pod replicas.

Step 7: Check Application Logs

If the ingress and pods look healthy but you still receive a 503 Service Temporarily Unavailable error, check the application logs.

Run:

# kubectl logs <pod-name> -n <namespace>

Look for errors such as:

application startup failed.
database connection failed.
out of memory.
port binding failed.

If Application Startup Failed

This Usually means:

• Application crashed during startup.
• Required environment variables or Secret are missing.
• Configuration is incorrect.

Possible fixes:

• Verify environment variables.
• Verify secrets and configmaps.
• Check application startup commands.

If Database Connection Failed

This Usually means:

• Database is unreachable.
• Credentials are incorrect.
• Network connectivity issue exists.

Possible fixes:

• Verify database endpoint.
• Verify credentials.
• Verify network policies or firewall rules.

If Out Of Memory Errors Appear

This Usually means:

• Memory limit is too low.
• Application is consuming too much memory.

Possible fixes:

• Increase memory limits.
• Reduce application memory usage.
• Fix memory leaks.

How to Fix 503 Service Temporarily Unavailable in Linux

In Linux environments, a 503 Service Temporarily Unavailable error is commonly caused by:

• Overloaded backend applications.
• ackend services being unavailable.
• Aggressive Nginx rate limiting configuration.

One of the most common causes is Nginx rate limiting. Let’s go through the troubleshooting steps to identify and fix the issue.

Step 1: Check Nginx Error Logs

Run:

# tail -f /var/log/nginx/error.log

Look for errors such as:

limiting requests
no live upstreams
upstream timed out

These errors can help identify whether the issue is related to rate limiting, backend availability, or slow upstream responses.

Step 2: Check Rate Limiting Configuration

Example configuration:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location / {
    limit_req zone=mylimit burst=1 nodelay;
}

This configuration means:

• Each client IP is allowed only 1 request per second
• The additional requests may be rejected

During high traffic, Nginx may return a 503 Service Temporarily Unavailable error if the configured request limit is exceeded.

Step 3: Increase Rate Limits

If the traffic is legitimate, consider increasing the rate limit.

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

You can also increase burst size:

location / {
    limit_req zone=mylimit burst=20 nodelay;
}

Here:

• “burst=20” allows additional requests before they are rejected
• "nodelay” processes burst requests immediately instead of delaying them. If we will remove this parameter then the request will be in the queue.

Possible fixes:

• Increase the request rate
• Increase the burst size
• Remove overly aggressive rate limiting

Step 4: Check Backend Application Health

Run:

# curl http://localhost:5000

Replace http://localhost:5000 with your application’s endpoint if needed.

Examples:

#curl http://192.168.1.10:8080
OR
#curl http://myapp.example.com

If the backend responds slowly or does not respond at all:

• Application may be overloaded
• Upstream service may be unhealthy

Possible fixes:

• Restart the backend service.
• Optimize application performance.
• Increase server resources.

Step 5: Reload Nginx Safely

After making configuration changes, reload the Nginx service.

Run:

# nginx -t
# systemctl reload nginx

The nginx -t command validates the configuration before reloading Nginx.

Always verify the configuration before performing a reload to avoid introducing new issues.

Common Causes of 503 Service Temporarily Unavailable Errors.

Debugging Ingress Before Checking Endpoints.

Many engineers start troubleshooting:

• Ingress rules
• DNS
• Networking

Before checking whether the Service has healthy endpoints.

# kubectl get endpoints -n <namespace>

If the output shows:

<none>

The Service has no healthy backend pods available.

As a result, ingress has nowhere to send the request and may return a 503 Service Temporarily Unavailable error.

Using Heavy Readiness Endpoints

Using:

path: /

for readiness checks is often not the best approach.

If the / endpoint performs heavy processing:

• Readiness checks become slow
• Pods become NotReady
• Ingress may return 503 Service Temporarily Unavailable error

whenever possible use a lightweight health endpoint such as:

path: /health

Keeping timeoutSeconds Too Low

By default, Kubernetes waits only 1 second for a readiness probe response. Under high load, this can be too short.

Example:

timeoutSeconds: 5

Increasing timeoutSeconds gives the application more time to respond before Kubernetes marks the pod as unhealthy.

This can help prevent readiness probe failures during:

• High CPU usage.
• Traffic spikes.
• Slow application startup.

Confusing 502 and 503 Errors

Many engineers confuse 502 Bad Gateway and 503 Service Temporarily Unavailable errors because both are related to backend applications.

When error is 502 Bad Gateway

This usually means:

• Backend application is down
• Connection refused
• Wrong port configuration
• Backend service unreachable

If you’re troubleshooting a 502 error, check out our detailed guide on Nginx 502 Bad Gateway in Docker and Linux.

When error is 503 Service Temporarily Unavailable

This usually means:

• No healthy endpoints are available.
• Readiness probes are failing.
• Backend application is overloaded
• Nginx rate limiting is configured.

Quick rule to identify 502 or 503 error

If Nginx cannot reach the backend application, it is usually a “502 Bad Gateway“.

If Nginx has no healthy backend available to serve requests, it is usually a “503 Service Temporarily Unavailable“.

Conclusion

The 503 Service Temporarily Unavailable error is usually a symptom of an unhealthy or overloaded backend rather than an Nginx issue itself.

In Kubernetes, start by checking:

• Service endpoints
• Pod readiness
• CPU and Memory usage
• Ingress logs

In Linux environments, start by checking:

• Backend application health.
• Nginx error logs.
• Rate limiting configuration.

Following these checks in order can help you identify and resolve most 503 errors quickly.