HTTP 5xx response

Your server is replying, but it's telling you something went wrong on its end. DomainDash shows the site as Down because a 5xx response means visitors can't use the site.

Symptom

• DomainDash shows the site as Down. On the Uptime page, the latest Check history row shows the status code, for example HTTP 503
• Running curl -v https://example.com returns a 5xx status code (500, 502, 503, 504, 530, etc.)
• Visitors see a generic error page: "500 Internal Server Error", "502 Bad Gateway", "503 Service Unavailable", or a provider-specific error page (e.g. Cloudflare's error pages)
• Unlike a connection failure, the server is responding, with an error

What it means

A 5xx response code means the server itself is broken, overwhelmed, or has encountered an error it can't recover from. Unlike 4xx errors (which mean the request was rejected), a 5xx means something is wrong in your infrastructure: the application, the process, an upstream service, or the server itself. DomainDash shows a 5xx response as Down unless it is the Expected response you chose.

The exact code tells you which layer to look at:

Code	What it usually means
500 Internal Server Error	Application crashed: an unhandled exception, a missing environment variable, a misconfigured framework
502 Bad Gateway	Reverse proxy (Nginx, Caddy) reached the app layer but got a bad response. The app is likely down or stuck
503 Service Unavailable	Service is intentionally or accidentally unavailable: maintenance mode, auto-scaling lag, or the app refusing requests
504 Gateway Timeout	Reverse proxy timed out waiting for the app to respond. Similar to 502 but caused by slowness, not an outright failure
530 (Cloudflare)	Cloudflare can't reach your origin server. The server is down or blocking Cloudflare's IPs

Common causes

• Application threw an unhandled exception (500), often triggered by a bad deploy, a missing environment variable, or a misconfigured dependency
• The application server process is stopped or crashed (502, 503)
• A database connection is down or a critical upstream API is unavailable, causing every dependent request to fail
• The server is in maintenance mode (503), intentional, but DomainDash still shows it as Down unless that is the Expected response you chose
• Auto-scaling hasn't kept up with a sudden traffic spike and the remaining instances are overwhelmed (503, 504)
• A recent deploy introduced a regression that causes the app to crash on startup

How to fix

1. Identify the exact status code. Run:

   curl -v https://example.com

   Note the status code and the response body, since some frameworks include the exception type in the response even when showing an error page.

2. Check your application logs. SSH into the server and look for errors around the time the incident started:

   sudo tail -200 /var/log/nginx/error.log

   For application-level logs:

   # Laravel
   tail -100 /path/to/app/storage/logs/laravel.log
   
   # Node.js (pm2)
   pm2 logs --lines 100
   
   # systemd service
   journalctl -u your-app-service -n 100

   Look for stack traces, exception names, and any pattern that correlates with the start of the downtime.

3. Check for a recent deploy. Open the Check history card on the site's Uptime page and look at when the Down status started. If it correlates with a deploy timestamp, a rollback is often the fastest fix:

   git revert HEAD
   # or deploy the previous release tag via your CI/CD pipeline

4. Check upstream services. For 502 and 504, the app server is unreachable or unresponsive. Verify the process is running:

   sudo systemctl status php-fpm
   # or
   pm2 status

   Test database connectivity directly:

   psql -h <database-host> -U <user> -d <database>

   A database that's down, unreachable, or exhausted its connection pool is one of the most common causes of sudden 500/502 errors.

5. Restart the application and verify. Restart the affected process:

   sudo systemctl restart php-fpm
   # or
   sudo systemctl restart your-app

   Then confirm the 5xx is gone:

   curl -v https://example.com

How to verify

Confirm visitors get your page:

1. Run curl -v https://example.com. The response should start with HTTP/2 200.
2. Open the site in a fresh browser window. It should load without an error page.
3. Open the site in DomainDash. After the first passing check the site page header reads Recovering, and once recovery is confirmed it reads Healthy. If uptime for the selected timeframe (24 hours by default) is under 97%, it reads Unstable until the figure recovers.

Related

• HTTP 4xx response — if the server is rejecting the request rather than erroring
• Connection timeout — if the server stops responding rather than returning an error code
• Site is down — if you're not sure which uptime issue you have
• How incidents work — how DomainDash confirms and notifies about downtime
• Uptime — how DomainDash runs uptime checks