Site down? 502, 503, and 504 errors, blank pages, and database connection errors

On the last day for property tax payments, a county's communications office starts getting calls: the website shows "504 Gateway Timeout." Someone refreshes, the page loads, and everyone assumes it is fixed. Twenty minutes later it fails again, and the ticket that finally arrives says only "website is down." The error page was the best clue, because each code points to a different part of the system.

What the error tells you

A website has layers: a CDN or load balancer, a web server, the application, and a database. The error tells you which layer gave up.

If the error page looks plain or carries a CDN's name instead of your site's design, the CDN usually could not reach your server. The problem is behind the CDN, not in it.

Five checks before you open a ticket

1. Is it just you? Load the site on a phone using mobile data, not your office network. If it works there, the problem may be your network, VPN, or DNS rather than the site.
2. Is it the whole site or one part? Try the home page, an inner page, and your CMS sign-in page. One failing page, form, or search is usually less urgent than a full outage.
3. Is it constant, or on and off? Errors that come and go usually point to load or a slow outside service; a constant error usually points to a recent change.
4. What changed recently? Updates, a deployment, a large import, a DNS change, or a deadline sending unusual traffic.
5. Capture the evidence. Screenshot the full error with the address bar, and note the time and URL.

What not to do while the site is down

• Do not keep refreshing. On an overloaded site, every refresh adds load.
• Do not update, reinstall, or switch off plugins and modules on the live site to "see if it helps." Each change hides the cause and can turn one problem into two.
• Do not restore a backup on your own. A restore can lose recent form entries and payments, and it hides the cause.
• Do not edit configuration files such as wp-config.php or settings.php directly on the live server.

Notes by platform

WordPress: when a plugin or theme causes a fatal error, WordPress shows "There has been a critical error on this website" and emails a recovery mode link to the administration email address under Settings, General. The email usually names the plugin that failed, and the link lets an administrator sign in and deactivate it. A "Briefly unavailable for scheduled maintenance" message that does not go away usually means an update was interrupted.

Drupal: an administrator can see the actual error under Reports, Recent log messages, if the Database Logging module is on. If visitors report a maintenance message that you do not see, check whether maintenance mode is on: administrators can still browse the site normally while it is.

Cascade: published pages are static files, so error pages on the live site come from the web server or CDN, not from Cascade. If the live site works but Cascade itself will not load for authors, the issue is with the Cascade application rather than your hosting; say which one you are seeing in your ticket.

Is it a P1?

If the whole public site, or a critical service such as payments, applications, or sign-in, is down for everyone, it is a P1 (Critical). Open a ticket, then call; see calling support for critical issues. One page, an intermittent error, or a slow site is usually P2 or P3; see severity levels and response times. If pages show content you did not add or redirect somewhere unexpected, treat it as a security incident; see if your site is hacked: the first hour.

How eWay handles outages

On environments eWay manages, monitoring runs around the clock with automated alerting to an on-call engineer, and incidents are triaged in under 15 minutes. Signals include uptime, error rates, page load time, and database, certificate, and DNS health, so eWay is often working on a full outage before you notice. Your report still matters: monitoring sees that something failed; you know what people were trying to do. Every P1 incident gets a formal root cause analysis; see resolution notes and root cause analysis.

What to include in a support ticket

• The severity you would assign, P1 to P4
• The exact error text or code, with a screenshot that includes the address bar
• The URLs affected, and whether it is the whole site or one part
• When it started, and whether it is constant or on and off
• Whether it also fails on mobile data
• Anything that changed recently: updates, deployments, imports, DNS

eWay customers can open a ticket in the support portal or email support@ewaycorp.com, which is monitored 24x7. Related reading: updating WordPress and Drupal safely and scaling WordPress and Drupal for traffic spikes.