Site broke overnight with no deploy: DNS, TLS, cache, and expiry checks

TL;DR — If the site worked yesterday and nobody deployed, the problem is usually outside your app code: DNS changed, the TLS certificate (the HTTPS identity file) expired, the server ran out of disk, a database connection failed, or a cache/CDN (content delivery network) is serving a bad result. Start with the cheapest checks: open the site in an incognito window, check your DNS and certificate in your provider dashboard, then check hosting alerts and disk/database status. Reading time: ~6 min

The scenario

It is Tuesday afternoon. Your site was fine yesterday, nobody merged code, and now customers are sending screenshots of "Your connection is not private", "502 Bad Gateway", or a blank page that spins forever. You check your agency chat and there was no deploy, no plugin update, no content import, nothing. That usually means something around the app changed on its own: DNS records, certificates, storage, a scheduled renewal, or an upstream service your site depends on.

Symptoms

• Browser shows certificate warnings such as:

  Your connection is not private
  NET::ERR_CERT_DATE_INVALID
  SSL_ERROR_BAD_CERT_DOMAIN
  

• Browser shows gateway or origin errors:

  502 Bad Gateway
  503 Service Unavailable
  504 Gateway Timeout
  Error 521 Web server is down
  Error 522 Connection timed out
  

• Browser shows DNS failures:

  This site can’t be reached
  DNS_PROBE_FINISHED_NXDOMAIN
  Server IP address could not be found
  

• The site works on mobile data but not office Wi‑Fi, or works in one country but not another.
• Hosting dashboard shows alerts like:

  Disk usage 100%
  Certificate expired
  Database connection refused
  Origin unreachable
  

• Application or web server logs contain lines such as:

  no space left on device
  connect() failed (111: Connection refused) while connecting to upstream
  FATAL: remaining connection slots are reserved
  too many connections
  

Likely causes

Step-by-step diagnosis

1. Check whether the problem is global or local to your browser/network.
   Open your site in an incognito/private window, then try on mobile data with Wi‑Fi turned off.

   • This is your problem if: it fails on office Wi‑Fi but works on mobile data, or fails only in one browser. That points to DNS cache, local network filtering, or a stale CDN path. Go to Fixes → CDN/cache/WAF is serving a stale error or blocking traffic.
   • If it fails everywhere: continue.

2. Check DNS in your provider dashboard.
   In your DNS provider's dashboard (for example: DNS → Records), inspect the root domain (@) and www.

   • This is your problem if: the A/AAAA/CNAME record points somewhere unexpected, is missing, or the domain status shows expired/hold. Go to Fixes → DNS record changed, expired, or is resolving to the wrong place.
   • CLI option if you have it:

   dig yourdomain.com +short
   dig www.yourdomain.com +short
   

   If the answers do not match your expected IP/hostname, treat DNS as the issue.

3. Check the TLS certificate from the browser.
   Open https://yourdomain.com, click the padlock or certificate details in the browser.

   • This is your problem if: the certificate is expired, not yet valid, or issued for the wrong hostname. Go to Fixes → TLS certificate expired or renewal failed.
   • CLI option:

   openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
   

   If notAfter is in the past, renewal failed.

4. Check hosting alerts, disk, and process health.
   In your hosting dashboard, open the server/app page and look for metrics or alerts: CPU, memory, storage, restarts, failed health checks.

   • This is your problem if: disk is near 100%, the app is crash-looping, or health checks are failing. If disk is full, go to Fixes → Server disk is full. If the app cannot reach its database or queue, go to Fixes → Database or app dependency is down or rejecting connections.
   • CLI option:

   df -h
   

   If the main filesystem is 95% or more, fix disk first.

5. Check database/service status and connection errors.
   In your database provider or hosting dashboard, open the database instance/service page and review status and recent events.

   • This is your problem if: status is degraded, restarting, storage full, or logs show connection refused/too many connections. Go to Fixes → Database or app dependency is down or rejecting connections.
   • CLI/log option:

   grep -E "connection refused|too many connections|remaining connection slots|timeout" /var/log/nginx/error.log /var/log/* 2>/dev/null | tail -n 20
   

6. Bypass or purge the CDN/cache.
   In your CDN/provider dashboard, purge cache for the site, or temporarily set the main DNS record to DNS-only/unproxied if your provider supports that wording.

   • This is your problem if: the site starts working immediately when bypassing the proxy/CDN. Go to Fixes → CDN/cache/WAF is serving a stale error or blocking traffic.

7. Check billing/domain status last.
   In your registrar and hosting billing dashboard, check notices and renewal dates.

   • This is your problem if: the domain is expired, on hold, or hosting is suspended. Go to Fixes → Domain or hosting subscription/payment issue caused suspension.

Fixes

DNS record changed, expired, or is resolving to the wrong place

Open your DNS provider dashboard and correct the record values for @ and www.

Typical examples:

Type: A
Name: @
Value: 203.0.113.10
TTL: Auto

Type: CNAME
Name: www
Value: app.example-host.com
TTL: Auto

If the domain itself expired, renew it in your registrar dashboard, then remove any clientHold/suspension state if your registrar shows one.

CLI check after the change:

dig yourdomain.com +short
dig www.yourdomain.com +short

Verify it worked: both hostnames resolve to the expected IP/target, and the site loads from mobile data and office Wi‑Fi.

TLS certificate expired or renewal failed

First try your hosting/provider dashboard: look for SSL/TLS, Certificates, or Domains, then click Renew, Reissue, or Run certificate provisioning.

If you manage the server yourself with Certbot:

sudo certbot renew --force-renewal
sudo systemctl reload nginx

If the certificate covers the wrong hostname, reissue it for both root and www:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

If renewal fails because DNS points elsewhere, fix DNS first, then rerun renewal.

Verify it worked:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

The notAfter date should be in the future, and the browser warning should disappear.

Server disk is full, so the app or web server cannot write temp/log/session files

⚠️ Deleting files can remove logs you may need later. If you are not sure what a file is, download a backup copy before deleting it.

Dashboard-first: in your hosting panel, open the file manager or storage view and sort by size. Common safe cleanup targets are old compressed logs, old backups stored on the server, and application cache directories.

CLI options:

df -h
sudo du -xh / | sort -h | tail -n 20
sudo find /var/log -type f -name "*.gz" -delete
sudo journalctl --vacuum-time=7d

Common app cache cleanup examples:

rm -rf tmp/cache/*
rm -rf var/cache/*

Then restart the web/app service:

sudo systemctl restart nginx
sudo systemctl restart php-fpm || true
sudo systemctl restart your-app-service || true

Verify it worked: df -h shows free space available, and the site returns 200 OK instead of 502/503.

Database or app dependency is down or rejecting connections

Dashboard-first: restart the affected managed service from your provider dashboard if it is stuck in restarting or degraded, and check whether storage or connection limits were hit.

If you manage the app server yourself, restart the app and confirm the database settings are still present:

sudo systemctl restart your-app-service
printenv | grep -E "DATABASE_URL|DB_HOST|DB_NAME|DB_USER"

For Postgres connection pressure, a short-term fix is to restart the app workers that are leaking connections, then add pooling later:

sudo systemctl restart your-app-service

If the database storage is full, increase storage in the provider dashboard or delete old data/logs according to your application's retention policy.

Verify it worked: the database/service status is healthy, and new page loads no longer show 500, 502, or timeout errors.

CDN/cache/WAF is serving a stale error or blocking traffic

In your CDN/provider dashboard, use Cache → Purge or Purge everything. If your provider supports proxy toggles, temporarily switch the main DNS record to DNS only/unproxied, wait a minute, and test again.

If you have access to the origin server, purge app caches too:

rm -rf var/cache/*
rm -rf tmp/cache/*
sudo systemctl reload nginx

If there is a WAF/security rule page, review recent blocked requests for your own IP or for the site path returning errors, then disable the offending custom rule.

Verify it worked: the site loads when bypassing the proxy, and continues to load after a cache purge.

Domain or hosting subscription/payment issue caused suspension

In your registrar and hosting dashboards, update the payment method, pay any outstanding invoice, and renew the domain or service. If the dashboard shows suspended, use the Reactivate or Unsuspend action after payment clears.

If the domain expired and DNS was removed, re-add the required records after renewal.

Verify it worked: the dashboard status changes to active, DNS answers again, and the site returns a normal page.

Prevention

1. Add certificate expiry monitoring. Set an alert at 30, 14, and 7 days before expiry.

   openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
   

   Put this in a daily monitoring job and alert if fewer than 30 days remain.

2. Monitor DNS changes and registrar expiry. Turn on change notifications in your DNS/registrar dashboard, and store the expected records in version control:

   @    A      203.0.113.10
   www  CNAME  app.example-host.com
   

   Review this file whenever someone edits DNS.

3. Alert on disk usage before it is critical. Add alerts at 80%, 90%, and 95% for the server filesystem and database storage.

   df -h
   

   If your host supports metric alerts, create them in the server/instance monitoring page.

4. Run an external health check from more than one region. Monitor both the homepage and a dynamic page like /login or /api/health.

   curl -I https://yourdomain.com/
   curl -I https://yourdomain.com/login
   

   Alert on 5xx, certificate errors, and DNS failures.

5. Pin and document renewals and background jobs. If you use Certbot, confirm the timer exists and ran recently:

   systemctl list-timers | grep certbot
   systemctl status certbot.timer
   

   Keep a short runbook with the exact renewal command and the expected DNS records.

6. Keep backups off the app server. Old backups filling the same disk as the website are a common cause of overnight failures. Move backups to object storage or your provider's backup service, and delete local copies after upload:

   find /backups -type f -mtime +7 -delete
   

   Test restore quarterly so cleanup does not become risky guesswork.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.