Apache + Cloudflare Tunnel Downtime SOP - IT Operations Notes
OPS-001 · Incident SOP

Apache + Cloudflare Tunnel
Downtime SOP

A practical operations note for restoring and hardening a self-hosted Raspberry Pi web server when Cloudflare Tunnel reports origin service downtime.

1033
Cloudflare Error
3
Fixes Applied
Pi 4
Target Host
2026
Documented
Incident Summary

The public site was unreachable, but the tunnel was not the root problem.

munyakazi.org periodically became unavailable with Cloudflare Error 1033. The visible symptom pointed to the Cloudflare Tunnel path, but the diagnosis showed that cloudflared was still active and connected. Apache was the service that had stopped.

User impact Portfolio and contact form unavailable during the incident window.
Pattern Repeated over several weeks and correlated with daily log rotation.
Resolution

The fix combined root-cause correction and recovery hardening.

The SOP changed Apache logrotate behavior from reload to graceful, added a systemd restart policy for Apache, and created a 1 GB swap file as a preventive buffer on the Raspberry Pi.

Problem Statement

What failed

The browser showed a Cloudflare Tunnel error and reported that the origin service could not be reached. The site recovered only after physical Raspberry Pi reboots, which made the failure operationally disruptive and worth converting into a formal SOP.

01
Cloudflare symptom
The public error was Cloudflare Error 1033, which means Cloudflare could not reach the configured tunnel origin.
02
Service impact
The website and contact path were unavailable, so the incident affected both portfolio visibility and communication.
03
Recurring trigger
The pattern was periodic and aligned with Apache log rotation behavior rather than a random network outage.
Root Cause Analysis

How the failing layer was isolated

The investigation checked the tunnel, Apache, memory state, Apache logs, and logrotate configuration. This separated the Cloudflare-facing symptom from the actual origin-service failure.

01
Tunnel status checked
cloudflared was active with registered tunnel connections, so the tunnel process itself was not the primary fault.
sudo systemctl status cloudflared
02
Apache status checked
Apache was stopped at the time of the error. Restarting Apache restored the website.
sudo systemctl status apache2
03
Memory ruled out
Available memory and kernel logs did not show an out-of-memory kill, so memory pressure was not the immediate cause.
free -h dmesg | grep -i 'killed'
04
Apache log signal found
Apache logs showed a graceful shutdown signal, which pointed toward reload behavior during maintenance tasks.
sudo grep -i 'caught signal' /var/log/apache2/error.log
05
Logrotate source identified
The Apache logrotate postrotate action used reload, which was sending the signal that caused Apache to shut down without recovering cleanly.
sudo cat /etc/logrotate.d/apache2
Applied Fixes

Three changes made the service recoverable

Fix 1

Change logrotate reload to graceful

The primary fix updated Apache log rotation so daily rotation reloads Apache safely instead of triggering the failing shutdown behavior.

sudo nano /etc/logrotate.d/apache2 # postrotate: invoke-rc.d apache2 graceful 2>&1 | logger -t apache2.logrotate
Fix 2

Add systemd restart policy

A systemd override was added so Apache can automatically recover if it unexpectedly stops again.

sudo systemctl edit apache2 [Service] Restart=always RestartSec=10 sudo systemctl daemon-reload
Fix 3

Add 1 GB swap file

The Pi had no swap configured. A small swap file was added as a preventive safety buffer for future workloads.

sudo fallocate -l 1G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Verification

How the fix was validated

  • Forced Apache log rotation and confirmed Apache stayed active after the rotation event.
  • Checked systemctl status apache2 and verified the systemd drop-in override was listed.
  • Confirmed free -h showed a 1 GB swap line instead of the previous 0B swap state.
  • Confirmed the public site remained reachable without requiring a physical Raspberry Pi reboot.
Rollback Plan

Safe reversal path

The SOP also documents how to reverse the changes if needed: revert Apache logrotate to its previous reload behavior, remove the Apache systemd override, reload systemd, disable swap, remove the fstab entry, and delete the swap file.

sudo systemctl revert apache2 sudo systemctl daemon-reload sudo swapoff /swapfile # remove /swapfile line from /etc/fstab sudo rm /swapfile

From Incident to Operating Knowledge

This note is part of the IT Operations Notes library: practical documentation for real fixes, service recovery, and infrastructure troubleshooting.