Repository files, collaboration, releases and project activity.
ARCHFORGE HISTORY
Blame · FIX-HTTP-302-1.0.4.md
Branch main · the Commit author is not necessarily a verified ArchForge account.
6b0b538dd6archadmin2026-10-11
1 # Fix HTTP 302 false outage — ArchForge External Status v1.0.46b0b538dd6archadmin2026-10-11
2 6b0b538dd6archadmin2026-10-11
3 ## Symptom6b0b538dd6archadmin2026-10-11
4 6b0b538dd6archadmin2026-10-11
5 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.6b0b538dd6archadmin2026-10-11
6 6b0b538dd6archadmin2026-10-11
7 ## Git-based fix on VPS 26b0b538dd6archadmin2026-10-11
8 6b0b538dd6archadmin2026-10-11
9 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.6b0b538dd6archadmin2026-10-11
10 2. On Debian 13 VPS 2, if you are already root:6b0b538dd6archadmin2026-10-11
11 6b0b538dd6archadmin2026-10-11
12 ```bash6b0b538dd6archadmin2026-10-11
13 cd ~/archforge-external-status6b0b538dd6archadmin2026-10-11
14 git pull --ff-only6b0b538dd6archadmin2026-10-11
15 bash ./apply-monitor-fix.sh6b0b538dd6archadmin2026-10-11
16 ```6b0b538dd6archadmin2026-10-11
17 6b0b538dd6archadmin2026-10-11
18 If using a normal sudo user, run the last command with `sudo bash ./apply-monitor-fix.sh`.6b0b538dd6archadmin2026-10-11
19 6b0b538dd6archadmin2026-10-11
20 **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.6b0b538dd6archadmin2026-10-11
21 6b0b538dd6archadmin2026-10-11
22 ## Behavior6b0b538dd6archadmin2026-10-11
23 6b0b538dd6archadmin2026-10-11
24 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**.6b0b538dd6archadmin2026-10-11
25 6b0b538dd6archadmin2026-10-11
26 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.6b0b538dd6archadmin2026-10-11
27 6b0b538dd6archadmin2026-10-11
28 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.