---
id: fleet/a-deploy-report-verifies-pm2-not-that-the-app
title: 'A deploy verifies PM2, not that the app still works'
theme: fleet
status: open
created: 2026-08-21
date_source: stated
order: 4
---

**A deploy verifies PM2, not that the app still works.** The deploy commander raised this against itself,
unprompted, in its own report: _"Nothing was verified beyond `pm2`."_ That is the most valuable line in
either report so far and it should not be true twice more.

What step 6 checks today is that the process it restarted is `online` and that `restart_time` moved. That
catches a crash on boot. It does not catch a server that starts, listens, and serves a 500 — or one that
serves a stale bundle, which is the exact failure that cost an hour on 2026-08-21 when a rebuilt frontend
was never picked up because the running process still held the previous `index.gen.html`.

The check that would have caught all of it is one line and needs nothing built:

```bash
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:<port>/
```

Two things to settle rather than assume. **The port differs per host** — take it from that host's `.env`
(`OFFICERDEV_PORT`), not from a constant; `officer-dev` is 9000 and nothing guarantees the others are.
And **a 200 on `/` is a low bar**: it proves the SPA shell is served. An endpoint that touches Postgres
would prove more, and choosing one is the actual design question here — probably `/api/health` if it
exists, and if it does not, that is the smaller item to do first.

Worth adding to the plan format too, so a release can name its own smoke test rather than relying on a
generic one.