Visual verification · external probe

Source · Dan, 2026-06-22

"'Looks good from here' is not deploy verification. An independent witness — a screenshot service on a third-party network — is the only reliable check. It answers two questions in one shot: does it resolve from outside, and does the rendered page look right?"

The problem

"Looks good from here" is not deploy verification. The local browser cache, the local NextDNS resolver, the CF edge cache for your IP, the SSL cert that resolved an hour ago — all of these can show a working site while a real user on a different network sees a 404, a bad cert, or an asset that hasn't propagated. The class of bug this misses: curl works, browser fails. An independent witness is the only reliable check.

The probe answers two questions in one shot:

Does it resolve at all from outside? (DNS, cert, routing, propagation)
Does the rendered page look right? (assets loaded, fonts loaded, JS executed, no Rocket-Loader regressions)

If the local browser says "looks good" but no external probe has confirmed it, the deploy is unverified.

The element, in-page

The card below is the probe-result verdict card — the output surface this pattern produces after each deploy. Hit "Probe again" to watch it cycle through the pending state and resolve to a verdict. A real integration calls a screenshot API endpoint, captures the render, and writes a result like this to the status surface.

Where it applies

Custom-domain binding day on any new subdomain — curl alone can't catch SSL cert mismatch + CF Universal SSL propagation gaps; the probe catches both in one render.
Migration between hosting targets — Pages to Workers-with-Assets is a classic case where the new route looks fine locally but the run_worker_first asset-serving order can silently break the public URL.
Any deploy touching inline JS — Rocket Loader can break script execution even when the static HTML looks fine; the external render catches the visible symptom (blank widget, broken nav) that no curl check reveals.
Scheduled capture as an always-on signal — snapshots.gf.cx runs this loop continuously: external render → R2 push → status card. A broken card is an immediate visible alarm that the surface has regressed.

Reusable elements

Probe-result card — header (verdict badge · URL · re-probe button) + body rows (HTTP status · network · render time · timestamp) + attestation footer. Lift the HTML + CSS block from the demo above.
Pending state — header shifts to charcoal (#5a544d), badge pulses via @keyframes, value cells show …. One class toggle: card.className = 'probe-card pending'.
PASS / FAIL colour coding — PASS = forest green header (#1f6b3d); FAIL = red header (#a83333). Shared token set; consistent across every surface that renders a verdict.
UTC timestamp — always UTC in the "Probed at" field; readers in any zone can place the result on a shared axis without conversion.
Attestation footer — italic serif line confirming the witness is external and uncached. A prose signal, not a data field — it belongs at the bottom of the card, not in the rows.

Reference

Source: Dan, 2026-06-22 · codified from recurring "looks fine locally" deploy incidents across the portfolio.
In use / example: snapshots.gf.cx — the portfolio's always-on external visual probe. surface_snapshot.py captures each surface from an external network, pushes the JPEG to R2, and the status hub renders a probe-result card per surface. A broken card is the alarm. Also: srvc.gf.cx/transit — live probe-feed from an independent transit check.
Reusable elements: Probe-result card · pending state · PASS/FAIL colour tokens · UTC timestamp row · attestation footer (all listed above).
Origin: Useful external probes: WhereGoes (redirect chain + landing screenshot, free, no account); urltoscreenshot.com (clean visual capture, scriptable); RapidAPI screenshot endpoints (for CI / cron / deploy hooks).