Vigil: the site answers is failing
fixedopened 26 days agodown 85s
what the check said
the site answers — expected 200, got 502
Warden’s diagnosis · 90% sure of the cause
vigil is down with HTTP 502 because the vigil process is stopped in pm2 — the upstream proxy returns 502 when there is no origin on port 3100. Evidence from pm2_list: vigil has status "stopped", restartsSinceAdded=30, lastStartedAt 2026-09-14T22:27:54Z. The check has been flapping all day (109 passed, 11 failed, failing since 10:46:57Z). Evidence from pm2_logs: stdout shows clean Next.js 15.5.19 boots ("✓ Ready in …ms") on port 3100 each time, but the error stream is empty and the last boot's tail cuts off mid-startup ("✓ St…"). No stack trace — the process is being killed after coming up, not crashing on a code error. Consistent with an external kill (OOM, sweep process, host pressure). Timeline fits: lastPassedAt 22:28:31Z was vigil briefly up after its 22:27:54Z start; it died again before 22:29:43Z when this incident opened. Restarting vigil is the reversible fix the owner's standing rules call out.
suspect · vigil (pm2 process, stopped)
This one was worked before you opened the page, so there is nothing to watch live. Everything it did is in Everything it ran below, with the exact command and the rule that permitted each one — that table is the record, and this timeline is only the same thing arriving in real time.
vigil is down with HTTP 502 because the vigil process is stopped in pm2 — the upstream proxy returns 502 when there is no origin on port 3100. Fixed, and the check that failed passes again.
Everything it ran5 calls · 1 changed something
Warden has no shell. Each row below is one named action from a fixed list, spawned without a shell, with the rule of yours that permitted it. Copy any command and run it yourself.
| what | how safe | your rule | command | ms |
|---|---|---|---|---|
list the processes pm2_list | looks only | did ityou allowed it | pm2 jlist | 179 |
read the log pm2_logs | looks only | did ityou allowed it | pm2 logs vigil --lines 120 (errors only) | 186 |
read the log pm2_logs | looks only | did ityou allowed it | pm2 logs vigil --lines 80 | 196 |
read recent commits git_log | looks only | did ityou allowed it | git log -n 8 | 9 |
start the process pm2_start | undoes itself | did ityou allowed it | start vigil | 207 |
This incident is marked resolved because the site answers — the same check that failed — was run again and passed. Nothing Warden believed about its own fix could have closed it.