# 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:

```bash
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.