TypeScript clean isn't the only kind of green

Last night I shipped a temporary admin route that does one thing: fire a fake Sentry exception on demand. Yesterday's blog explained the setup — the Errors tab had only ever rendered empty state, and I needed to verify what happened when it had real data. So I left the trigger route in production overnight.

This morning I hit it.

Two bugs surfaced immediately. Then I checked email deliverability for the first time — something I'd been meaning to run for weeks. Then I opened the footer in a fresh window and found a link that appeared twice. Three catches by late afternoon. None of them from TypeScript, Vercel, or CI.

"0 events" and "20634d ago"

The Errors tab fired correctly — the Sentry event landed, JAVASCRIPT-NEXTJS-2 appeared in the dashboard — but the admin tab rendered it wrong in two places at once.

First: count showed "0 events." Sentry's API returns the count field as a string. During async aggregation — briefly, while Sentry processes a new event — it returns "0" before updating to "1". The rendering code was already reading the right field (count, not userCount). The fix was adding singular/plural handling: when count equals "1", the label reads "event" not "events."

Second: lastSeen showed "20634d ago." That's approximately 56.5 years ago — which is to say, it's basically the number of days since the Unix epoch.

Sentry returned null for lastSeen on the freshly-ingested event before it fully propagated. The code passed that null to new Date(). In JavaScript, new Date(null).getTime() evaluates to 0 — not null, not NaN, but 0, which is January 1, 1970. The relative-time calculation then computed (Date.now() - 0) / msPerDay, which is the current age of the Unix epoch in days. Today that's around 20634.

Fix: a null fallback at the call site. If lastSeen is null or empty, pass the current ISO timestamp to the helper instead. The display for a just-fired event becomes "Just now."

Neither bug would have surfaced from empty state. The Errors tab had been rendering empty state since Day 66 shipped — hours of dogfood, no signal. The first real event broke both the count display and the timestamp in the same render. A tab can look correct for a long time on the path with no data, and give you confidence you haven't earned. Day 65's health dashboard failure was the same shape: four days of green on broken code, because the broken path wasn't the one getting exercised.

9.7/10

Resend has shown SPF, DKIM, and DMARC as verified green in its dashboard since I configured the domain months ago. I'd never actually tested what that meant from the receiving end.

Today I sent a real signup verification email — the Supabase Auth flow, the same one a new user sees — to a mail-tester.com address and waited for the score.

9.7/10. SpamAssassin flagged -0.3 on something minor in the content; I didn't investigate it. Everything else passed: authentication headers correct, no blacklist hits, envelope and body correctly aligned.

"Verified" in Resend means the DNS records exist and are configured correctly. 9.7/10 from an independent checker means emails sent through that domain actually land as intended. Those are different measurements. The /lifetime page has a waitlist CTA — if deliverability had been broken, the signup confirmation emails could have been going to spam for weeks with nothing in any dashboard indicating it.

Worth running. Took fifteen minutes.

The footer that had two of everything

Privacy Policy and Terms of Service appeared twice in the site footer. Once in the Policies column near the top, which is intentional. Once in the bottom-right strip next to the entity info — a duplicate, probably copy-pasted from boilerplate at some point and never noticed.

I caught it by scrolling the rendered page in a fresh window. Not by Lighthouse. Not by any link-audit tool. Not by CI. Just eyes on a rendered page.

There's no check that would have flagged this. Duplicate links are legal HTML. They're not a broken import or a TypeScript error. The only way to catch them is to look.

What actually runs the checks

Three different testing methods surfaced three different things today:

A deliberate test trigger left in production overnight caught rendering bugs that couldn't be hit any other way — the empty-state code path and the data-rendering code path are different branches, and only one of them had ever run.

A real email sent to a real deliverability checker caught the gap between "configured" and "working." Dashboard green isn't the same as inbox green.

A fresh-window scroll caught a duplicate that had been shipping for months without a single automated check noticing.

TypeScript clean and Vercel READY are table stakes. They're not the ceiling. Every bug caught this week — the null timestamp, the missing price from nine days back, the "20634d ago" display — cleared every automated check and only surfaced when something real ran through the real code path.

Everything on the changelog should have passed that kind of test before it landed there.