How to check if Apache Web Server is running

One of the very first diagnostic steps I take whenever a website seems unreachable is checking whether Apache is actually running. It sounds like a basic question, but there are several reliable ways to answer it, and knowing all of them has saved me a lot of time over the years. In this guide, I’ll show you every method I use to check Apache’s status, from the quickest one-liner to deeper diagnostic techniques.

Why Checking Apache’s Status Matters

Before troubleshooting DNS, firewalls, or application code, I always rule out the simplest possible cause first: is the web server process even running? A surprising number of “my website is down” issues come down to Apache having crashed, been stopped manually, or failed to start after a reboot.

Prerequisites

• Access to the server via SSH or terminal.
• sudo privileges are helpful for some checks, though not strictly required for all of them.

Method 1: Using systemctl status

This is my go-to command on any modern Linux distribution using systemd.

On Ubuntu/Debian:

sudo systemctl status apache2

On CentOS/RHEL/Fedora:

sudo systemctl status httpd

The output tells me exactly what I need to know:

• Active: active (running) — Apache is up and serving requests.
• Active: inactive (dead) — Apache is not running.
• Active: failed — Apache attempted to start but crashed or hit an error.

This command also shows the process ID, memory usage, and recent log lines, which is often enough information to start troubleshooting immediately.

Method 2: Using the is-active Flag

If I just need a quick yes/no answer, ideal for scripts, I use:

sudo systemctl is-active apache2

This returns simply active or inactive, without the extra detail. It’s especially useful in shell scripts or monitoring checks where I want a clean, parsable result.

Method 3: Checking Running Processes

Another way to confirm Apache is running is to look directly at the process list:

ps aux | grep apache2

On CentOS/RHEL systems, the process name is usually httpd:

ps aux | grep httpd

If Apache is running, you’ll see multiple worker processes listed (the exact number depends on your MPM configuration), typically owned by the www-data (Ubuntu) or apache (CentOS) user, with one process usually owned by root as the parent.

Method 4: Checking Listening Ports

Even if a process shows up, I like to confirm Apache is actually listening on the expected network ports:

sudo ss -tulpn | grep apache2

or more generally, checking port 80 and 443:

sudo ss -tulpn | grep -E ':80|:443'

This tells me whether Apache has successfully bound to the ports it needs, which is a strong indicator that it’s not just running, but actually able to accept incoming connections.

Method 5: Testing with curl or wget

To confirm Apache is not just running but actually responding correctly, I test it directly:

curl -I http://localhost

I expect a response like:

HTTP/1.1 200 OK
Server: Apache/2.4.52 (Ubuntu)

If I get Connection refused, that’s a clear sign Apache isn’t listening, even if the process appears in the process list for some reason (which can happen with a hung or zombie process).

Method 6: Checking via a Web Browser

The simplest test of all, especially useful for a quick sanity check, is opening a browser and navigating to:

http://your_server_ip

or, on the local machine itself:

http://localhost

Seeing the default Apache welcome page or your actual website content confirms Apache is running and reachable.

Method 7: Checking the PID File

Apache typically maintains a PID (process ID) file that tracks its main process. I sometimes check this directly:

cat /var/run/apache2/apache2.pid

Then I cross-reference that PID with the running processes:

ps -p $(cat /var/run/apache2/apache2.pid)

If the process exists and matches, Apache is confirmed running under that PID.

Method 8: Reviewing the Apache Error Log

If Apache appears to not be running, I check the error log for clues about why it might have stopped or failed to start:

sudo tail -50 /var/log/apache2/error.log

This often reveals the exact reason, whether it’s a configuration syntax error, a port conflict, or a crash due to a misbehaving module.

Common Mistakes When Checking Apache’s Status

• Confusing a running process with a functioning web server. Apache can technically be running as a process while still failing to respond correctly due to configuration issues.
• Checking the wrong service name. On Debian-based systems it’s apache2; on RHEL-based systems it’s httpd. Using the wrong name gives a misleading “not found” or “inactive” result.
• Not checking the firewall. Apache can be running perfectly, listening on the correct port, and still be unreachable externally if the firewall blocks the port.
• Relying only on the browser test. DNS caching or browser caching can sometimes give misleading results; I prefer combining a curl test with a systemctl status check for certainty.

Setting Up Automated Monitoring

For production servers, I don’t want to manually check Apache’s status every time I’m worried about uptime. Instead, I set up monitoring using tools like:

• UptimeRobot or Pingdom for external HTTP checks.
• Monit or systemd’s built-in restart policies to automatically restart Apache if it crashes.
• Custom cron jobs running a simple health check script:

#!/bin/bash
if ! systemctl is-active --quiet apache2; then
    systemctl restart apache2
    echo "Apache was down and has been restarted at $(date)" >> /var/log/apache_monitor.log
fi

#!/bin/bash
if ! systemctl is-active --quiet apache2; then
    systemctl restart apache2
    echo "Apache was down and has been restarted at $(date)" >> /var/log/apache_monitor.log
fi

This kind of lightweight script has saved me more than once from a late-night outage that would otherwise have gone unnoticed until morning.

Security Considerations

When checking Apache’s status remotely, I make sure I’m not exposing sensitive server information unnecessarily. For example, I configure ServerTokens Prod in /etc/apache2/conf-available/security.conf so that a curl -I response doesn’t reveal detailed version numbers or OS information to potential attackers.

Performance Considerations

Regularly checking Apache’s status, whether manually or through automated monitoring, has a negligible performance impact, but I avoid overly frequent automated checks (like every second) that could add unnecessary load, especially on smaller VPS instances. A check every 30 to 60 seconds is generally more than sufficient for most monitoring needs.

Frequently Asked Questions

What’s the fastest way to check if Apache is running? sudo systemctl is-active apache2 gives an instant, clean answer.

Why does systemctl status show “running” but my site is still down? This usually means Apache is running but misconfigured, the firewall is blocking the port, or DNS isn’t pointing to the correct server.

How do I check Apache’s status without SSH access? You can test externally using curl -I http://your-domain.com from any machine, or simply visit the site in a browser.

Does a running Apache process guarantee my website works? Not necessarily. The process could be running while still returning errors due to configuration issues, missing files, or backend problems like a broken PHP script.

Summary and Key Takeaways

Checking whether Apache is running involves more than a single command; I combine systemctl status, process checks, port checks, and an actual HTTP request test to get a complete picture. For production environments, setting up automated monitoring takes this a step further, catching outages before they become a real problem. Knowing all these methods means I’m never stuck guessing when a site suddenly stops responding.

References

• Apache HTTP Server Documentation
• Ubuntu Server Documentation – Apache