Why not coverage
Coverage tells you how much of the code a test touched. It does not tell you whether the thing users pay for still works, or how bad it will be if it does not.
For a small team shipping weekly, the useful pre-release checks are the ones that predict how a bad release will feel in production.
One: error rate on the main workflow
Not the global error rate, which is dominated by bots and expired tokens. The error rate on the single sequence of requests that represents the product working.
We instrument that path explicitly and compare the candidate build against the current one on staging traffic. A rise there stops the release regardless of what the test suite says.
Two: p95 on the slowest query
Every product has one query that will eventually become the bottleneck. We track it by name, with the plan attached, and we look at it before shipping anything that touches its table.
Watching p95 rather than the median is deliberate: the median hides the request that makes someone reload the page.
Three: time to roll back
We measure this by doing it, not by estimating it. If a rollback takes more than a few minutes, the release is riskier than the diff suggests, and the fix is usually the deployment path rather than the code.
A short rollback time is what makes shipping weekly a calm activity instead of an event.