The page that had no row on the board
We track the load time of every screen. The guest ordering page had no line of its own, because it is served at the root of its own address.
Every screen in this product reports how long it took to appear, from the browser that drew it, and the owner's dashboard lists them slowest first against a 300ms budget. That board has eighty-eight rows on it. This morning we went looking for the guest ordering page — the QR menu, the thing a customer actually touches — and it was not one of them.
Not slow. Not fast. Absent.
A page is named after its address
The report says which page it is by taking the path out of the address bar.
For the back office that gives you /menu, /reports,
/dashboard — eighty-odd distinct, useful names. For a blog post it
gives you the post. It works everywhere we looked when we built it.
A vendor's menu is served at the root of its own address. So is a market's
hall page. The path is / — and so is the path of our own marketing
home page. Three different screens, all reporting the same one-character name,
all landing in the same row.
The comment above that code said, in as many words, that a vendor's QR page got its own line on the board. It was written by someone who had only ever opened the page the other way in, through a link that does carry the venue in the path. Half of a true statement, sitting directly above the code that made the other half false.
What the row was actually telling us
The / row read 1,924ms on average over a week, every one of its
twenty samples a cold first load, the worst of them 8,486ms. Read as the
marketing home page, that is an odd but survivable number for a brochure site.
Read correctly, it is something else entirely.
We can prove it is not the marketing page: that page makes no API call at all in its own document, and the row names one. We can prove it is guest-side traffic, because the call it names is the menu route. What we cannot say is whether it is the venue page or the hall, because both call that route and the address was thrown away before the number was stored. Three weeks of measurements that cannot be attributed to a screen.
So this change makes nothing faster. It renames three things. The guest page now reports as itself, the hall as itself, the staff app as itself, and the next reading of that board will be the first one that can see them.
The part worth taking away
A monitoring gap does not look like a problem. It looks like no problem. Nothing is red, nothing is missing from a list you are reading, because the list is the thing with the hole in it. We had a rule — anything over 300ms gets made faster — and an instrument we trusted, and the single most important surface in the product was outside both of them for weeks.
If you measure anything about your own operation, the question is not what the numbers say. It is which things never produce a number at all, and whether you would notice.