Skip to content

Repository files, collaboration, releases and project activity.

archforge-external-status / FIX-HTTP-302-1.0.4.mdmain
▤ FIX-HTTP-302-1.0.4.md1826 bytes

Fix HTTP 302 false outage — ArchForge External Status v1.0.4

Symptom

The external status page claims Main Website: Outage but the Debian 13 VPS records HTTP 302 in samples for the website. The old probe treated any redirect as a failure.

Git-based fix on VPS 2

  1. Put the 1.0.4 patch in your existing ArchForge Git repository, then commit and push. Never commit /etc/archforge-status/status.env, tokens, SQLite, or backup data.
  2. On Debian 13 VPS 2, if you are already root:
cd ~/archforge-external-status
git pull --ff-only
bash ./apply-monitor-fix.sh

If using a normal sudo user, run the last command with sudo bash ./apply-monitor-fix.sh.

Do not run ./update.sh as root: it is intentionally restricted to normal Git users. apply-monitor-fix.sh is for root, uses the existing safe deployer and installs code from the checkout. It backs up your database and retains a previous code release, without changing Caddy.

Behavior

After the service restarts, monitoring starts immediately and then every MONITOR_INTERVAL_SECONDS (normally 60 seconds). After MONITOR_RECOVERY_THRESHOLD consecutive good probes (normally 2), the Main Website status returns to operational and the previously automatic incident is closed. Existing failed samples and incident history are not erased.

A same-origin HTTPS 302 that eventually returns 200 counts as reachability only: it does not prove that authenticated features work. Cross-origin redirects, invalid TLS, repeated redirects, and 500 errors still fail. The optional API/Git probes remain strict.

If an unexpected redirect to another domain is involved, monitoring will still report a failure deliberately. In that case review TARGET_WEBSITE and the redirect destination rather than disabling the security checks.