I still remember a late night years ago when one of my early client sites went dark.

Browser said “connection refused”, the client was pinging my phone, and I was half-asleep with a kid on my shoulder. Classic. Turned out Apache wasn’t running at all — and I wasted way too much time poking at configs before I checked the actual service status.

This article is exactly what I wish I had back then: a simple, practical walkthrough of using systemctl to see what Apache is doing, and where to look first when things don’t look right.

Who This Is For (And The Core Problem)

You’re probably here because one of these is happening:

• Your site is down and you suspect Apache.
• apache2 or httpd won’t start or keeps stopping.
• You changed something (config, modules, etc.) and now Apache is acting weird.

You’re on a system that uses systemd (most modern Linux distros do), and you just want a clear way to ask the system: “Is Apache actually running? If not, why?”

We’ll focus on the basic but powerful status commands using systemctl, and what you should look at in the output.

Before You Touch Anything: Basic Safety

A few quick sanity checks before you begin poking around:

1. Use sudo or root
   The commands here all use sudo. If your user doesn’t have sudo, either switch to a user that does, or become root carefully.
2. Don’t randomly restart services on production
   If this is a live site with real users or customers, try to:
3. Check status first.
4. Plan restarts for a low-traffic time if possible.
5. If you’re about to edit configs, back them up first
   For example, before editing Apache config files, copy them somewhere safe. Just in case a typo makes things worse.

For this article, we’re only reading information from systemctl, so it’s safe. But once you know the status, you might be tempted to start/stop/restart — do that thoughtfully.

Step 1: Check Apache Status on Ubuntu/Debian

On Ubuntu and Debian, the Apache service is usually called apache2.service.

Run this command:

sudo systemctl status apache2.service -l --no-pager

A quick breakdown of the flags:

• -l
  Show the full output without truncating long lines. This matters because error messages often get cut off.
• --no-pager
  Send everything straight to your terminal instead of opening a pager (like less) that you have to scroll through.

You’ll see output similar to this:

● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: active (running) since Mon 2020-07-13 14:43:35 UTC; 1 day 4h ago
  Process: 929 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 1346 (apache2)
    Tasks: 55 (limit: 4702)
   CGroup: /system.slice/apache2.service
           ├─1346 /usr/sbin/apache2 -k start
           ...

Here’s what to focus on first:

1. The Active: line
2. If you see Active: active (running) like in the example, Apache is up and running.
3. If you expect the website to work but Active is not active (running), that’s your first red flag.
4. The Loaded: line
5. Confirms that systemd knows about the Apache service and whether it’s enabled at boot.
6. The Process: and Main PID: lines
7. Show how Apache was started and which process is the main one.

If Active doesn’t say active (running) and instead mentions failed, inactive, or dead, note that. You’ll use that info in the next steps.

Step 2: Check Apache Status on CentOS/Fedora

On CentOS and Fedora, the Apache service is usually called httpd.service.

Run this command:

sudo systemctl status httpd.service -l --no-pager

And you’ll see output like:

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd...
   Active: active (running) ...
   ...

Again, your main target is the Active line:

• Active: active (running) → Apache is running.
• Anything else when you expect it to be running → there’s probably an error or configuration issue you’ll need to track down.

Keep an eye on these parts:

• Active: line — tells you the current state.
• Loaded: line — confirms systemd has a valid unit file for Apache.

If there’s a problem, the status output will usually hint at it. Often you’ll see a line mentioning failed in the status, or an explanation message near the bottom of the output.

Step 3: Interpreting the Active Line (Healthy vs Broken)

Let’s zoom in on that Active line, because that’s the fastest way to know if Apache is healthy.

Typical healthy example (Ubuntu/Debian):

Active: active (running) since Mon 2020-07-13 14:43:35 UTC; 1 day 4h ago

This means:

• Apache is running.
• It has been running for over a day without issue.

If you expect the site to be up and you see that line, Apache is probably not your main problem. You’d then look at virtual host configs, firewall rules, DNS, etc. (outside the scope of this specific guide).

But if there is a problem with Apache itself, status output usually includes something like this (conceptually):

Active: failed (Result: exit-code) ...

or:

Active: inactive (dead)

When you see a failed or clearly non-running status and you expected it to be running, that’s when you know:

• Apache tried to start and hit an error, or
• Apache crashed or was stopped.

From here, your next move is to inspect further details — and often, that means going beyond systemctl status into log inspection with tools like journalctl or Apache’s own logs.

Step 4: When Status Shows Failed – What Next?

If systemctl status shows that Apache is not active (running) and indicates failure, you know two things:

1. Systemd tried to manage the Apache process and something went wrong.
2. The systemctl status output itself may include a hint of the error.

Typical next steps (conceptually) when you see a failure:

1. Read the full systemctl status output carefully
   With the -l flag, you might already see an error line telling you what went wrong. Scroll and read it; sometimes the explanation is right there.
2. Use journalctl for deeper troubleshooting
   The status output suggests that if there is a problem with your Apache process or configuration, you can troubleshoot it further using the journalctl command. That’s often the next layer of detail.
3. Check your recent changes
   Think about what you touched last:
4. Config files?
5. Modules?
6. Permissions?

If Apache was working before and now it’s not, undoing or reviewing your most recent change is usually faster than guessing blindly.

Remember: systemctl status is your “first look”. It tells you if Apache is running and gives you a quick summary. For deeper troubleshooting, you branch out from there.

Step 5: Quick Workflow You Can Reuse

Here’s a simple pattern I use whenever a site looks dead and I suspect Apache.

On Ubuntu/Debian

1. Check status

bash
sudo systemctl status apache2.service -l --no-pager

1. If Active: active (running)
2. Apache is running. Troubleshoot further at the app or network level.
3. If Active is not active (running)
4. Note any failed or error lines in the output.
5. Plan to dig deeper (logs, configs, etc.), starting from what systemctl shows.

On CentOS/Fedora

1. Check status

bash
sudo systemctl status httpd.service -l --no-pager

1. If Active: active (running)
2. Apache is running. Look elsewhere for the issue.
3. If Active indicates failure or not running
4. Read the status output fully.
5. Use that as your starting point for more detailed troubleshooting.

This alone won’t fix every problem, but it keeps you from flailing around. You always start with: “Is the service actually running? What does systemd say about it?”

Wrap-Up

When Apache acts up, running straight to configs or blaming WordPress themes is tempting, but checking the service status with systemctl is faster and cleaner.

On Ubuntu/Debian:

sudo systemctl status apache2.service -l --no-pager

On CentOS/Fedora:

sudo systemctl status httpd.service -l --no-pager

Then focus on the Active line and any obvious error hints. From there, you can decide if you need to dig into logs, configs, or something higher up the stack.

Need more help? Check the latest CrushEdge posts.