Repository files, collaboration, releases and project activity.
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
- 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. - 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.