How to Fix Server Down and Website Inaccessible Quickly

Every system administrator, developer, or website owner will face this scenario at some point: your server goes down, your website becomes inaccessible, and users — or worse, clients — start sending messages asking what's wrong. Your heartbeat quickens. Every second of downtime costs money, reputation, and user trust.

This guide is your complete, actionable playbook for diagnosing and resolving server downtime and website inaccessibility as quickly as possible — from the moment you detect the problem to full recovery and post-incident review.

---

Table of Contents

• Understanding Server Downtime: Causes and Types
• Immediate First Response: The First 5 Minutes
• Systematic Diagnosis: Step-by-Step Troubleshooting
• Common Causes and Their Fixes
• Prevention: Building a Resilient Infrastructure
• Monitoring Setup for Early Detection
• Creating an Incident Response Runbook
• Post-Incident Review
• Server Down FAQ
• Conclusion and Recommendations
• Additional SEO Data

---

Understanding Server Downtime: Causes and Types

Before you can fix a problem quickly, you need to understand what you're dealing with. Server downtime broadly falls into two categories:

Full Server Downtime

The server is completely unreachable — SSH won't connect, ping returns nothing, and the web interface is unresponsive. This is the most severe scenario.

Common causes:

• Hardware failure (disk crash, memory failure, NIC failure)
• Power outage at the data center
• Network infrastructure issue (upstream provider, BGP routing problem)
• Cloud provider outage
• Kernel panic or OS crash
• Resource exhaustion (disk 100% full, OOM killer terminates critical processes)

Partial Downtime / Website Inaccessible

The server is running and SSH works, but the website is returning errors (502, 503, 504, 500) or timing out.

Common causes:

• Web server (Nginx/Apache) crashed or hung
• Application server (PHP-FPM, Node.js, Gunicorn) crashed
• Database (MySQL/PostgreSQL) crashed or overloaded
• Memory exhausted — applications getting OOM-killed
• CPU spike from a runaway process or DDoS attack
• Disk full — application cannot write logs, sessions, or uploads
• SSL certificate expired
• DNS misconfiguration or propagation issue
• Misconfigured firewall blocking port 80/443

---

Immediate First Response: The First 5 Minutes

The first 5 minutes after detecting downtime are critical. Don't panic — follow this checklist in order.

Step 1: Confirm the Downtime (30 seconds)

Before anything else, confirm this isn't just a local network issue on your end.

# Check from your local machine
ping your-server-ip
curl -I <https://yourdomain.com>

# Use external tools to verify
# downforeveryoneorjustme.com
# uptimerobot.com
# isitdownrightnow.com

Also check:

• Down For Everyone Or Just Me — confirms whether the site is globally down
• Your monitoring tool (UptimeRobot, Datadog, Pingdom) — check when the alert was first triggered
• Cloud provider status page — AWS Status, GCP Status, DigitalOcean Status

Step 2: Attempt SSH Connection (60 seconds)

ssh -v user@your-server-ip

Three outcomes:

1. SSH connects → The server OS is alive. Problem is at the application layer. Proceed to application-level diagnosis.
2. SSH times out → Network or OS-level problem. Check cloud console for server status.
3. SSH connection refused → SSH daemon crashed or firewall is blocking port 22. Try cloud provider's web console/VNC.

Step 3: Communicate Status (2 minutes)

Don't wait until you have a fix to communicate. Immediately:

• Post a status update on your status page (Cachet, Statuspage.io)
• Notify your team via Slack/Teams
• If SLA-critical: notify affected clients proactively

A simple template:

"We are currently investigating an issue affecting [service]. Our team is actively working on a resolution. We will provide an update in 15 minutes."

Proactive communication dramatically reduces the volume of incoming support tickets and preserves trust.

---

Systematic Diagnosis: Step-by-Step Troubleshooting

Once SSH is established, work through this diagnosis funnel — from infrastructure layer up to application layer.

Layer 1: Infrastructure Health

# Check overall system health in one command
uptime && free -h && df -h && top -bn1 | head -20

# Memory: is the system under memory pressure?
free -h
# Look for: Mem available close to 0, large swap usage

# Disk: is any filesystem at 100%?
df -h
# Also check inodes (can be exhausted even when disk space is free)
df -i

# CPU: is anything consuming 100% CPU?
top -bn1 | sort -k9 -rn | head -10
# Or use htop for interactive view
htop

# Load average: compare to number of CPU cores
nproc  # number of CPU cores
cat /proc/loadavg  # 1min, 5min, 15min load
# Load > CPU cores = system is overloaded

Layer 2: Network Connectivity

# Is the server's public IP reachable?
ip addr show

# Check listening ports — is the web server actually listening?
ss -tlnp | grep -E ':80|:443|:3000|:8080'

# Check firewall rules
sudo iptables -L -n -v
# Or for UFW:
sudo ufw status verbose

# Is port 80/443 accessible from outside?
# From another machine:
nc -zv your-server-ip 80
nc -zv your-server-ip 443

Layer 3: Web Server Status

# Nginx
sudo systemctl status nginx
sudo nginx -t  # test configuration syntax
sudo tail -100 /var/log/nginx/error.log
sudo tail -100 /var/log/nginx/access.log

# Apache
sudo systemctl status apache2
sudo apache2ctl configtest
sudo tail -100 /var/log/apache2/error.log

# Restart if crashed (only after checking logs for root cause)
sudo systemctl restart nginx
# or
sudo systemctl restart apache2

Layer 4: Application Server Status

# PHP-FPM
sudo systemctl status php8.1-fpm
sudo tail -50 /var/log/php8.1-fpm.log

# Node.js (PM2)
pm2 status
pm2 logs --lines 50
pm2 restart all  # if processes are errored/stopped

# Python (Gunicorn)
sudo systemctl status gunicorn
journalctl -u gunicorn -n 100

# Laravel (check storage/logs)
tail -100 /var/www/your-app/storage/logs/laravel.log

Layer 5: Database Status

# MySQL/MariaDB
sudo systemctl status mysql
sudo tail -50 /var/log/mysql/error.log

# Try connecting manually
mysql -u root -p -e "SHOW STATUS LIKE 'Uptime';"

# Check for locked tables
mysql -u root -p -e "SHOW PROCESSLIST;"

# PostgreSQL
sudo systemctl status postgresql
sudo tail -50 /var/log/postgresql/postgresql-*.log
psql -U postgres -c "SELECT pid, state, query FROM pg_stat_activity LIMIT 20;"

Layer 6: System Logs — The Final Arbiter

# Check kernel and system logs for hardware errors or OOM events
sudo dmesg | tail -50
sudo dmesg | grep -E 'error|fail|OOM|killed'

# Check systemd journal for recent failures
journalctl -p err -n 100
journalctl -p err --since "1 hour ago"

# Check auth log for potential brute force / unauthorized access
sudo tail -100 /var/log/auth.log

---

Common Causes and Their Fixes

Fix 1: Disk Full (100% Disk Usage)

Disk full is one of the most common causes of website downtime — and one of the easiest to miss until it's too late.

# Find disk usage by directory
du -sh /* 2>/dev/null | sort -rh | head -20
du -sh /var/log/* | sort -rh | head -10

# Find and remove large old log files
find /var/log -name '*.gz' -mtime +7 -delete
find /var/log -name '*.log' -size +100M

# Clear journal logs older than 3 days
sudo journalctl --vacuum-time=3d

# Remove old Docker images/containers
docker system prune -a  # WARNING: removes all unused images

# Clear apt cache
sudo apt-get clean

# Check for large files anywhere on the system
find / -xdev -type f -size +100M 2>/dev/null | sort -k5 -rn

For inodes exhausted (df -i shows 100%):

# Find directories with massive numbers of small files
for i in /*; do echo $i; find $i -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -k 1 -rn | head -5; done

# Common culprit: PHP sessions directory
ls /var/lib/php/sessions/ | wc -l  # if millions of files, clear old ones
find /var/lib/php/sessions -type f -mtime +1 -delete

Fix 2: Out of Memory (OOM) / Memory Exhaustion

# Check if OOM killer has been active
sudo dmesg | grep -i 'out of memory'
sudo dmesg | grep -i 'killed process'

# Identify memory hogs
ps aux --sort=-%mem | head -20

# If Apache is consuming too much memory, check worker count
# In /etc/apache2/mods-enabled/mpm_prefork.conf:
# Reduce MaxRequestWorkers

# For PHP-FPM: check pm.max_children
grep 'pm.max_children' /etc/php/8.1/fpm/pool.d/www.conf

# Temporary relief: add swap (if no swap exists)
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# Make permanent:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Fix 3: Web Server / Application Crashed

# Quick restart sequence (Nginx + PHP-FPM)
sudo systemctl restart php8.1-fpm
sudo systemctl restart nginx

# For Node.js with PM2:
pm2 restart all
pm2 save

# Verify services started successfully
sudo systemctl status nginx php8.1-fpm

# If Nginx fails to start, always check config first:
sudo nginx -t
# Fix the reported config error, then:
sudo systemctl start nginx

Fix 4: Database Down or Overloaded

# Restart MySQL (verify no data corruption first)
sudo systemctl stop mysql
sudo systemctl start mysql

# If MySQL won't start, check for corruption:
sudo mysqlcheck --all-databases -u root -p

# Check for long-running queries blocking everything
mysql -u root -p -e "SHOW FULL PROCESSLIST;"
# Kill a blocking query:
mysql -u root -p -e "KILL QUERY process_id;"

# MySQL connection limit exhausted?
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"
# Temporarily increase:
mysql -u root -p -e "SET GLOBAL max_connections = 500;"

# For PostgreSQL: check max connections
psql -U postgres -c "SHOW max_connections;"
psql -U postgres -c "SELECT count(*) FROM pg_stat_activity;"

Fix 5: CPU Spike / Runaway Process

# Identify the process consuming CPU
top -bn1 | sort -k9 -rn | head -10
# or
ps aux --sort=-%cpu | head -10

# If it's a legitimate process (MySQL, PHP) under load:
# - Check if there's a traffic spike (DDoS, viral content, crawler)
grep "$(date +'%d/%b/%Y:%H')" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# If it's a runaway/zombie process:
kill -9 PID

# If DDoS suspected, block offending IPs:
sudo iptables -A INPUT -s OFFENDING_IP -j DROP
# Or use Fail2ban if already installed:
sudo fail2ban-client status

Fix 6: SSL Certificate Expired

# Check certificate expiry
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

# If using Let's Encrypt / Certbot:
sudo certbot renew --force-renewal
sudo systemctl reload nginx

# Check auto-renewal timer is active:
sudo systemctl status certbot.timer
# If not active:
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

Fix 7: DNS Issue / Domain Not Resolving

# Check DNS resolution
nslookup yourdomain.com
dig yourdomain.com +short
dig yourdomain.com ANY

# Check from multiple DNS resolvers:
dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com

# If DNS is correct but propagation is slow:
# - Check DNS TTL (lower TTL before making changes)
# - Use dnschecker.org to see propagation globally

# If server IP changed recently:
# - Update A record at your DNS provider
# - Low TTL = faster propagation (300 seconds = 5 minutes)

Fix 8: Firewall Blocking Port 80/443

# Check UFW status
sudo ufw status verbose

# Open ports if blocked:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw reload

# Check iptables directly:
sudo iptables -L INPUT -n -v --line-numbers
# Remove a blocking rule by line number:
sudo iptables -D INPUT LINE_NUMBER

# Check cloud provider security groups (AWS, GCP, DO)
# These are separate from OS-level firewall
# Must allow inbound TCP 80 and 443 from 0.0.0.0/0

---

Prevention: Building a Resilient Infrastructure

The best incident response is not needing one. These practices dramatically reduce the frequency and impact of downtime.

1. Set Up Automated Disk Cleanup

# Add to /etc/cron.daily/cleanup-logs
#!/bin/bash
find /var/log -name '*.gz' -mtime +14 -delete
find /var/log -name '*.log' -mtime +30 -size +50M -exec truncate -s 0 {} \;
journalctl --vacuum-size=1G
docker system prune -f 2>/dev/null || true

2. Configure Proper Log Rotation

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        nginx -s reopen
    endscript
}

3. Configure Swap Space

Always have swap — it's the difference between a brief slowdown and a complete crash when memory spikes.

# Recommended: swap = 1x RAM for servers with 1-4GB RAM
# For 2GB RAM server:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Set swappiness (lower = use RAM longer before swapping)
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

4. Set Up Automated Backups

#!/bin/bash
# /usr/local/bin/daily-backup.sh
DATE=$(date +%Y%m%d)
BACKUP_DIR="/backups"
DB_NAME="your_database"

# Database backup
mysqldump -u root -p"$DB_PASS" "$DB_NAME" | gzip > "$BACKUP_DIR/db-$DATE.sql.gz"

# Files backup
tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" /var/www/your-app

# Keep only last 7 days
find "$BACKUP_DIR" -name '*.gz' -mtime +7 -delete

# Sync to remote storage (optional but recommended)
aws s3 sync "$BACKUP_DIR" s3://your-backup-bucket/server-backups/

5. Resource Limit Configuration

Prevent any single process from taking down the entire server.

For Nginx + PHP-FPM (WordPress/Laravel):

# /etc/php/8.1/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20        ; max concurrent PHP processes
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500       ; recycle workers after N requests (prevents memory leaks)

For MySQL:

# /etc/mysql/mysql.conf.d/mysqld.cnf
max_connections = 150
innodb_buffer_pool_size = 512M  ; ~50-70% of available RAM
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

---

Monitoring Setup for Early Detection

The goal is to detect problems before your users do. A solid monitoring stack gives you this.

Tool	What It Monitors	Alert Method	Free Tier
UptimeRobot	HTTP/HTTPS, ping, port	Email, Slack, SMS	50 monitors free
Better Uptime	Uptime + screenshot on failure	Phone call, Slack	10 monitors free
Netdata	CPU, RAM, disk, processes	Email, Slack	Fully free on-premise
Prometheus + Grafana	Full metrics stack	AlertManager	Fully open source
Datadog	Infrastructure + APM + logs	PagerDuty, Slack	Free for 5 hosts
Zabbix	Enterprise infrastructure	Email, SMS, custom	Fully open source

Minimum Viable Monitoring Setup

For a production server with limited budget, this combination covers the essentials:

1. UptimeRobot (free) — external HTTP check every 5 minutes, alerts via email + Telegram
2. Netdata (free, on-server) — real-time CPU/RAM/disk/process monitoring with built-in alerts
3. Logwatch — daily email digest of critical log entries

# Install Netdata (one-line installer)
bash <(curl -Ss <https://my-netdata.io/kickstart.sh>)

# Install Logwatch
sudo apt-get install logwatch
# Configure:
echo 'MailTo = admin@yourdomain.com' | sudo tee -a /etc/logwatch/conf/logwatch.conf
echo 'Detail = Med' | sudo tee -a /etc/logwatch/conf/logwatch.conf

Critical Alerts to Configure

Don't alert on everything — alert fatigue is real. Focus on conditions that require immediate action:

# Netdata alert examples (/etc/netdata/health.d/custom.conf)

alarm: disk_space_critical
    on: disk.space
 lookup: average -5m
  units: %
  every: 1m
   warn: $this > 85
   crit: $this > 95
   info: Disk space is critically low
     to: sysadmin

alarm: ram_available_critical
    on: system.ram
 lookup: average -5m of avail
  units: MB
  every: 1m
   warn: $this < 256
   crit: $this < 128
   info: Available RAM is critically low
     to: sysadmin

---

Creating an Incident Response Runbook

A runbook is a documented procedure your team follows during an incident. Having it ready before an incident occurs is what separates teams that resolve issues in minutes from those that scramble for hours.

Runbook Template: Website Inaccessible

# Incident Runbook: Website Inaccessible

## Severity Levels
- P1 (Critical): Production completely down, affecting all users
- P2 (High): Degraded performance affecting >50% of users  
- P3 (Medium): Partial outage affecting <50% of users

## Escalation Path
1. On-call engineer (immediate)
2. Engineering lead (if unresolved after 15 min)
3. CTO / management (if P1 unresolved after 30 min)

## Step 1: Triage (0–5 minutes)
- [ ] Confirm downtime from external tool (isitdown.site)
- [ ] Check monitoring dashboard
- [ ] Check cloud provider status page
- [ ] Attempt SSH to production server
- [ ] Post initial status update to status page

## Step 2: Diagnose (5–15 minutes)
- [ ] Check disk usage: df -h
- [ ] Check memory: free -h
- [ ] Check CPU: top -bn1
- [ ] Check web server: systemctl status nginx
- [ ] Check app server: pm2 status / systemctl status php-fpm
- [ ] Check database: systemctl status mysql
- [ ] Check error logs: tail -100 /var/log/nginx/error.log

## Step 3: Fix and Verify
- [ ] Apply fix based on root cause
- [ ] Verify service is responding: curl -I <https://yourdomain.com>
- [ ] Monitor for 10 minutes after fix
- [ ] Post resolution update to status page

## Step 4: Document
- [ ] Record timeline in incident log
- [ ] Schedule post-mortem within 48 hours

---

Post-Incident Review

The incident is resolved — but the work isn't done. A proper post-mortem is what prevents the same incident from happening again.

Post-Mortem Framework (Blameless)

The goal of a post-mortem is not to find who caused the incident — it's to find what systemic factors allowed it to happen and how to prevent recurrence.

Questions to answer:

1. Timeline — When did the incident start? When was it detected? When was it resolved?
2. Impact — How many users were affected? What was the estimated revenue impact?
3. Root Cause — What was the actual technical cause? (Not symptoms, but root cause)
4. Contributing Factors — What made this worse or harder to detect?
5. Detection — How was the incident detected? By monitoring or by user reports?
6. Response — What did the team do well? Where was response slow or ineffective?
7. Action Items — What specific changes will be made to prevent recurrence? Who owns each item? By when?

Post-Mortem Template

## Incident Post-Mortem: [Brief Description]
**Date:** YYYY-MM-DD
**Duration:** X hours Y minutes
**Severity:** P1/P2/P3
**Author:** [Name]

### Summary
[2-3 sentence summary of what happened and the impact]

### Timeline
- HH:MM — First alert triggered / user report received
- HH:MM — On-call engineer acknowledged
- HH:MM — Root cause identified
- HH:MM — Fix applied
- HH:MM — Service fully restored

### Root Cause
[Specific technical explanation of what caused the incident]

### Contributing Factors
- [Factor 1]
- [Factor 2]

### What Went Well
- [Thing 1]

### What Could Be Improved
- [Improvement 1]

### Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| Set up disk usage alert at 80% | @engineer | 2026-06-22 | Open |
| Add logrotate config for /var/log/app | @engineer | 2026-06-22 | Open |

---

Server Down FAQ

1. My server is completely unreachable via SSH — what should I do?

First, check your cloud provider's web console — AWS EC2 console, DigitalOcean Droplet console, Hetzner Cloud console. These provide out-of-band access that bypasses the network. Check if the server shows as running. If it does but SSH still fails, use the provider's web console/VNC to access the terminal directly and investigate from there.

2. The website was working, I changed the Nginx config, and now it's down. How do I roll back?

# If you have a backup of the previous config:
sudo cp /etc/nginx/sites-available/yourdomain.com.backup /etc/nginx/sites-available/yourdomain.com
sudo nginx -t && sudo systemctl reload nginx

# If you don't have a backup, check nginx config syntax for the error:
sudo nginx -t
# Fix the reported line number, then reload

Going forward: always run sudo nginx -t before reloading, and keep config files in a Git repository.

3. The site shows a 502 Bad Gateway error. What does that mean?

502 Bad Gateway means Nginx is running but cannot reach the upstream application server (PHP-FPM, Node.js, etc.). Check:

# Is PHP-FPM running?
sudo systemctl status php8.1-fpm
# Is Node.js running?
pm2 status
# Does the upstream socket/port match Nginx config?
ss -tlnp | grep -E ':9000|:3000|:8080'

4. My website is slow but not completely down. How do I diagnose it?

# Check server load
uptime
# Check for slow MySQL queries
mysql -u root -p -e "SHOW PROCESSLIST;"  
# Check Nginx access log for unusual patterns
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Use ab to test response time:
ab -n 100 -c 10 <https://yourdomain.com/>

5. How do I know if I'm being DDoS attacked?

# Check for massive number of connections from single or multiple IPs
netstat -tn 2>/dev/null | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Check access log for unusual request patterns
tail -10000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

# If confirmed DDoS:
# 1. Enable Cloudflare (if not already)
# 2. Block attacking IPs with iptables
# 3. Enable rate limiting in Nginx
# 4. Contact your hosting provider — they can null-route the attack

6. Is it safe to restart MySQL during an active incident?

Generally yes, but with caution. MySQL's InnoDB engine is crash-safe — it will replay its transaction log on restart. However:

• Always check for active connections/transactions first: SHOW PROCESSLIST;
• If there's active data being written, a forced restart can result in a brief recovery period on restart
• For databases with heavy write load, prefer FLUSH TABLES WITH READ LOCK; before shutdown for a cleaner stop

7. My disk is full but I can't find what's filling it up. What do I do?

# Interactive disk usage explorer
sudo du -h --max-depth=3 / 2>/dev/null | sort -rh | head -30

# Check for deleted files still held open by running processes
sudo lsof +L1 | grep deleted
# These files are logically deleted but still consuming disk space
# Restart the process holding them open to release the space

# Truncate a large log file without restarting the service:
> /var/log/large-file.log  # truncates to zero bytes

8. How do I set up a fast rollback strategy for deployments?

For zero-downtime rollback, maintain the last 3 deployment releases:

# Deployment directory structure:
# /var/www/your-app/releases/20260615120000/
# /var/www/your-app/releases/20260614120000/
# /var/www/your-app/current -> releases/20260615120000 (symlink)

# Rollback = just point the symlink to the previous release:
ln -sfn /var/www/your-app/releases/20260614120000 /var/www/your-app/current
sudo systemctl reload nginx

# Laravel Envoyer and Capistrano use this exact pattern automatically

---

Conclusion and Recommendations

Server downtime will happen — no system has 100% uptime forever. The difference between a team that recovers in 5 minutes and one that struggles for 3 hours comes down to three things: preparation, monitoring, and process.

Quick Reference: Diagnosis Checklist

• [ ] Confirm downtime externally (not just from your network)
• [ ] Check cloud provider status page
• [ ] Attempt SSH — is the OS alive?
• [ ] Check disk: df -h and df -i
• [ ] Check memory: free -h
• [ ] Check CPU/load: uptime and top
• [ ] Check web server: systemctl status nginx
• [ ] Check application server: pm2 status / systemctl status php-fpm
• [ ] Check database: systemctl status mysql
• [ ] Check error logs: tail -100 /var/log/nginx/error.log
• [ ] Check system logs: dmesg | tail -50 and journalctl -p err -n 50
• [ ] Check firewall: ufw status / iptables -L
• [ ] Check SSL: openssl s_client -connect domain:443
• [ ] Check DNS: dig yourdomain.com

Recommended Action Plan by Priority

This week:

• Set up external uptime monitoring (UptimeRobot — free)
• Configure disk usage alert at 80% threshold
• Verify logrotate is configured for all application logs
• Add swap space if not already present

This month:

• Create and document your incident response runbook
• Implement automated daily database backups with offsite storage
• Set up server metrics monitoring (Netdata or Prometheus + Grafana)
• Test your backup restore procedure — an untested backup is not a backup

This quarter:

• Implement a staging environment that mirrors production
• Set up a CI/CD pipeline to eliminate manual deployments
• Conduct a chaos engineering exercise — intentionally cause a failure in staging and run through your runbook
• Consider a CDN (Cloudflare) for DDoS mitigation and performance

When your server goes down at 2 AM, you won't have time to search for solutions. Having a runbook, solid monitoring, and practiced procedures is what gets you back online fast — and what keeps you sleeping soundly the rest of the time.

---

Call to Action

Have you experienced a server outage that cost you hours to resolve? Share your experience in the comments — what was the root cause, and what did you put in place afterward to prevent it from happening again?

Found this guide useful? Share it with your team or save it as a reference for your next incident. And check out these related articles:

• 📌 25 Linux Commands Every Professional Server Administrator Must Master — the command-line foundation for everything in this guide
• 📌 Understanding DevOps: Definition, Tools, and Benefits — the culture and practices that make incidents less frequent
• 📌 How to Manage a Linux VPS for Beginners — the foundational guide to server administration

---

Additional SEO Data

Primary Keyword: server down fix, website not accessible, how to fix server down

LSI Keywords: server downtime troubleshooting, nginx not working, website 502 bad gateway, disk full server, MySQL crashed, VPS down, website inaccessible fix

Semantic Keywords: incident response, site reliability, uptime monitoring, server administration, Linux troubleshooting, web server restart, disaster recovery

Long Tail Keywords: how to fix server down quickly, website showing 502 bad gateway fix, what to do when VPS is down, server disk full website down, how to diagnose server downtime

Question Keywords: why is my website down?, how do I fix a 502 error?, what causes server downtime?, how to restart Nginx after crash?

Entity Keywords: Nginx, Apache, MySQL, PostgreSQL, PHP-FPM, PM2, Node.js, Certbot, Let's Encrypt, UptimeRobot, Netdata, DigitalOcean, AWS, Cloudflare

---

Meta Title: How to Fix Server Down and Website Inaccessible Quickly

Meta Description: Complete guide to diagnosing and fixing server downtime and website inaccessibility — step-by-step commands for disk full, memory exhaustion, Nginx crash, database down, and more.

Slug: how-to-fix-server-down-website-inaccessible-quickly

Blogger Tags: Server Administration, Linux, DevOps, Nginx, MySQL, Uptime, Incident Response, VPS, Troubleshooting, SRE

Category: Linux, Server Administration, DevOps, Cloud Infrastructure

Alt Image: Server downtime troubleshooting flowchart showing diagnosis steps

Caption Image: A systematic approach to diagnosing server downtime — from infrastructure layer to application layer

---

{
  "@context": "<https://schema.org>",
  "@type": "Article",
  "headline": "How to Fix Server Down and Website Inaccessible Quickly",
  "description": "Complete incident response guide for server downtime and website inaccessibility — systematic diagnosis, common fixes, prevention strategies, and monitoring setup.",
  "author": {
    "@type": "Person",
    "name": "CloudAdminHub"
  },
  "publisher": {
    "@type": "Organization",
    "name": "CloudAdminHub"
  },
  "datePublished": "2026-06-15",
  "dateModified": "2026-06-15",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "<https://cloudadminhub.blogspot.com/2026/06/how-to-fix-server-down-website-inaccessible-quickly.html>"
  }
}

{
  "@context": "<https://schema.org>",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What should I do first when my server goes down?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "First confirm the downtime from an external source (not your local network), then attempt SSH access. If SSH connects, check disk, memory, CPU, and service status in that order. If SSH fails, use your cloud provider's web console for out-of-band access."
      }
    },
    {
      "@type": "Question",
      "name": "What does 502 Bad Gateway mean and how do I fix it?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "502 Bad Gateway means Nginx is running but cannot reach the upstream application (PHP-FPM, Node.js, etc.). Check if your application server is running with 'systemctl status php8.1-fpm' or 'pm2 status', restart it if it's stopped, then verify Nginx can reach it."
      }
    },
    {
      "@type": "Question",
      "name": "How do I prevent disk full from causing server downtime?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Set up a disk usage alert at 80% threshold, configure logrotate for all application logs, schedule automated cleanup of old log files and Docker images, and monitor inode usage in addition to disk space."
      }
    }
  ]
}

OG Title: How to Fix Server Down and Website Inaccessible Quickly

OG Description: A complete incident response playbook — systematic diagnosis commands, common fixes for disk full, memory exhaustion, Nginx/MySQL crashes, and prevention strategies for Linux VPS servers.

twitter:card = summary_large_image
twitter:title = How to Fix Server Down and Website Inaccessible Quickly
twitter:description = Complete server troubleshooting guide — diagnosis, fixes, and prevention for Linux VPS downtime. Covers Nginx, MySQL, disk full, OOM, SSL, DNS, and more.

---

Recommended External Links:

• Nginx Official Documentation
• MySQL Server Administration Manual
• Let's Encrypt / Certbot Documentation
• Netdata Documentation
• DORA State of DevOps Report