Uptime monitoring answers one question: does the server respond? It answers it well, from many places, every minute. It is table stakes, and you should have it. It is also almost never the thing that goes wrong.
What goes wrong is that the server responds and the business does not. Checkout returns 200 with an error message in the body. The nightly agent finishes on time with three times its usual cost. A deploy succeeds and quietly breaks the pricing table. Every monitor is green. The customer is the one who tells you.
The gap is between availability and promises. A company makes a handful of promises it can name: customers can pay, production matches the code we shipped, the agents we run finish within budget, the messages we send arrive. None of those is an HTTP status code.
This is why the useful page is not an uptime page. It is an internal status page: one row per promise, coloured by whether the promise held today, with the evidence one click away. It looks like the status pages vendors publish for their customers, pointed inward.
Building one is mostly plumbing. The tools already emit the events: Stripe knows about the payment, GitHub knows about the deploy, your agent knows its cost. What is missing is a place where they land together and a rule that reads them together. A place where a failed payment spike and a deploy ten minutes earlier are one row, not two tabs.
Once the rows exist, the interesting work is deciding what counts as normal. Two failed payments an hour might be nothing for you and an emergency for someone else. The only baseline that matters is your own, over your own last ninety days.
Keep your uptime monitor. Then add the page that tells you whether the company is working, not just whether the machine is on. That is what InternalStatus is.