Website down? How to find out why

When a site goes down, the temptation is to restart everything and hope. It sometimes works, but you learn nothing and the problem returns. It is faster to find where the request breaks.

A visit passes through steps in order: the browser resolves the name through DNS, opens a secure connection using the TLS certificate, reaches a server or proxy, and finally your application answers. Each step fails in a recognizable way. The error you see tells you which one failed.

Is the site really down, or is it just me?#

Before touching the server, confirm the scope. Three one-minute tests:

1. Open the site on your phone's mobile data, off Wi-Fi.
2. Run curl from another machine or a server.
3. Ask someone else to open it.

If it loads elsewhere, the problem is local: a stale DNS cache, a VPN, antivirus, a browser extension or your ISP. Flush the cache with ipconfig /flushdns (Windows) or sudo resolvectl flush-caches (Linux with systemd).

If it fails everywhere, the problem is on the site's side. Move on to the next step.

How do I read the error?#

curl shows where the request stopped more clearly than a browser does:

curl -sS -o /dev/null -w "%{http_code}\n" -v https://yoursite.com

Is DNS resolving the domain?#

Test with:

nslookup yoursite.com
dig +short yoursite.com

If no IP comes back, check two things. First, whether the domain expired at the registrar: it is the most mundane cause and one of the most common. Then whether the A or CNAME record still exists. More in DNS_PROBE_FINISHED_NXDOMAIN and DNS propagation.

If you just changed DNS, results may differ for a while: different resolvers keep the old value until the TTL runs out.

Did the certificate expire?#

Let's Encrypt certificates are short-lived, and the official FAQ recommends renewing them well before they expire. In December 2025, Let's Encrypt announced a gradual reduction of the default lifetime, so renewal has to be automatic. If automatic renewal fails silently (a stopped cron job, port 80 blocked, DNS changed), the site "goes down" with an expired certificate warning.

echo | openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates

The notAfter line is the expiry date. More in SSL certificate errors and how Let's Encrypt works.

What do 502, 503 and 504 mean?#

These are the scariest errors, and all of them point at the application behind a reverse proxy:

• 502 Bad Gateway: the proxy talked to the application and got an invalid response, for example because the process crashed during the request or is not listening where the proxy expects.
• 503 Service Unavailable: the server cannot handle the request right now, because of overload or maintenance.
• 504 Gateway Timeout: the proxy got no response from the application in time.

In all three cases, go to the application log. Look for out-of-memory (Killed, JavaScript heap out of memory, MemoryError), an unhandled exception at startup, or the wrong port. A Node.js server must listen on the port and address the proxy expects:

import http from "node:http";

const port = Number(process.env.PORT) || 3000;
http
  .createServer((req, res) => res.end("ok"))
  .listen(port, "0.0.0.0", () => console.log(`listening on port ${port}`));

Listening only on 127.0.0.1, or on a port the proxy does not know about, produces a 502 even though the application is "running".

What if it is a 500 error or a blank page?#

Here the server is up and your code broke. Check the log at the time of the error and compare with your last deploy. Frequent causes: an environment variable that exists on your machine but not on the server, a dependency that was not installed, a database refusing connections, and a file missing from the deploy. If it started right after publishing, roll back to the previous version first and investigate afterwards.

How do I prevent the next outage?#

• Turn on automatic domain renewal and check the registrar's contact email.
• Use an external monitor that tests the URL every few minutes and notifies you by email, SMS or webhook.
• Keep logs and watch memory and CPU, so you see the limit approaching before it is hit.
• Make sure the application restarts on its own when the process fails.
• Keep a rollback path to the previous deploy.
• If the site does not need server-side code, consider a static site: fewer parts can break.

How to do this on Square Cloud#

On Square Cloud, your site runs in an isolated container that is always on; with automatic restart on (the default for dashboard deploys), an application that exits with an error comes back by itself. You see live logs in the dashboard, the CLI and VS Code. CPU, RAM and network metrics, collected every 5 minutes and kept for 24 hours, show whether memory ran out before the crash. Running out of memory stops the application, and it stays stopped until you raise its RAM and start it again.

Every web application gets a *.squareweb.app subdomain with HTTPS, which helps separate a domain problem from an application problem: if the subdomain opens and your domain does not, the fault is on the domain side (DNS records or the domain itself), not in the application. On a custom domain (from the Standard plan), the dashboard shows DNS record validation status in real time, and TLS is automatic.

Web analytics, included in every plan, shows visits, routes and status codes; Pro and Enterprise add HTTP logs. There are no email alerts, so use an external monitor to get notified.

To get started, see the site hosting page; monitoring details are on the analytics page.