The status page is linked from the board that cannot carry its history
Decided
the service board on /support#status carries a link to status.novelsystems.ca, the monitoring provider's own status page, stated as the place past incidents and scheduled maintenance are published.
Affects: app/support/page.tsx, config/site.ts (STATUS_URL, now imported by something).
What was wrong. STATUS_URL has been exported from config/site.ts since the subdomain was provisioned and was imported by nothing. The only route to that page from anywhere we control was a /status redirect in next.config.mjs, which a visitor has to already know exists in order to type. Meanwhile the footer entry labelled "System Status" points at /support#status — our own board, which is a snapshot with no memory. So the site had a real, independently hosted status page with seven days of per-service history, and no reader could find it.
Why a second panel rather than a sentence in the first. The panel above the link explains how to read the rows. This one answers a different question, and it is the question a buyer actually has: not "is it up right now", which they can see, but "does this thing go down often", which the board structurally cannot answer because it holds no history at all.
The independence claim is load-bearing. The copy says the status page is hosted by the monitoring provider rather than by us, and that is the reason it is worth linking: it does not share a failure domain with the API it reports on, so it is still reachable in the one case where anybody urgently wants it. Moving that page behind our own infrastructure would make the sentence false and the page useless at the same moment.
Why the copy does not mention email subscription. Better Stack status pages can offer one; this one, as served today, shows Status, Maintenance, Previous incidents, and Get in touch, and no subscribe control was observed. Describing a feature that is one settings toggle away from being true is still describing a feature that is not there.