DomainDash could tell you a client's site was up. Not that it actually worked. Just shipped the fix.
DomainDash could tell you a client's site was up. Not that it actually worked. Just shipped the fix.
When I launched DomainDash, every check answered one question: did the site respond? That's useful right up until the server returns a cheerful 200 OK over a homepage reading "Database connection error" — or a bad deploy quietly removes the checkout. The site is "up". It's also broken.
So this week: content checks.
You give a site one assertion that should always hold on the page:
Text: a word or phrase that should be there (your price, "Add to basket", the footer copyright).
Element: a CSS selector that should exist (the checkout form, the booking widget).
Data: a JSON fragment an API response should still contain ({"status":"ok"}).
If it fails, the site is marked Down and you get the same urgent incident you'd get if it had gone offline — email, Slack, SMS. You hear about it before your client does.
Two decisions I'm happy with:
The page never comes back to us. The assertion runs out at the edge checker (Rust), and only a yes/no verdict returns — we never store what was on the page. Felt wrong to start hoovering up client page contents just to confirm a word was present.
It's honest about what it can't do. The checker reads the HTML your server sends, before any JS runs. If your page is rendered entirely client-side, it sees the empty shell — so we say that up front rather than letting a check fail mysteriously.
Full write-up with screenshots: http://localhost:5200/updates/content-checks-2026-06-30/
If you point it at a real page, the thing I'd most value: does the incident wording read right the day something actually breaks? That's the moment it has to be clear, and it's the bit I most want torn apart. Content checks are on Pro — all new sign-ups get a free 30 day trial.
