A secret is verified by its shape before it is saved, never by its content

What went wrong

UPTIME_MONITOR_API_KEY was set in Vercel and the deployment went green. CI passed. The deployment reported Ready. And /support rendered:

The uptime monitor could not be reached: Cannot convert argument to a ByteString because the character at index 492 has a value of 8212 which is greater than 255.

Nothing in the repository was wrong. lib/uptime-monitor.ts was correct, its tests passed, and the failure was a faithful report of its input: the value in the environment variable was roughly 490 characters of prose ending in an em dash (code point 8212), not a token. The "Copy to clipboard" click on the vendor's one-time reveal banner had never registered — a synthetic click does not satisfy the browser's user-activation requirement for the clipboard API — so the subsequent paste inserted whatever the clipboard had held before.

The failure mode that matters is not the bad paste. It is that a stale clipboard is silent. Cmd+V always succeeds. The field masks its contents, so the wrong value looks exactly like the right one, and the first evidence arrives one build and one page-load later, phrased as a character-encoding error that does not obviously mean "you pasted the wrong thing".

What was changed

Two guards, both cheap, neither requiring the secret to be read:

1. 1.Seed the clipboard with a sentinel — CLIPBOARD-NOT-REPLACED-COPY-STEP-FAILED — before asking for a copy. A repeat of this failure then writes an unmistakable string into the field instead of plausible-looking prose.
2. 2.Verify shape, not content. Before saving, read back only { length, first three characters, contains-whitespace }. A Better Stack Uptime API token is 24 characters with no whitespace; the corrected paste reported len: 24, startsWith: "GVr", hasSpace: false. That is sufficient to reject every failure observed here and insufficient to reconstruct the token.

The tell that should have been caught by eye: the masked dot row filled the entire width of the field. Twenty-four characters cannot do that.

The alternative, and why not

The obvious alternative is to validate the token server-side after saving — call the monitor once and surface the result. That is worth having, but it is a *later* signal, not a substitute: it runs after a build, after a deploy, and it reports through the same channel that already reported this failure accurately and was not read for eleven minutes. Checking the shape at the moment of paste costs one expression and fails in the same breath as the mistake.

It is also the only check available that does not require handling the secret. Reading the value back to compare it against the vendor's page would mean the value passing through a context that must never see it. Length is not the secret.

What would make this wrong

A credential format with no fixed length and no stable prefix — a JWT, a PEM block, anything whose legitimate values span two orders of magnitude — makes the length check useless and the prefix check nearly so. For those, the sentinel still works (it is a positive test for "the copy happened"), but the shape check degrades to "not the sentinel, and not empty". At that point the server-side validation call stops being a nice-to-have and becomes the primary guard.