Checks

"We catch breakage, the customer does not." Every night, Gerry re-tests your map against your live site without you having to notice something broke first.

What runs, and when

At 03:00 UTC, a scheduled job walks every active tenant that has a site map and checks it against the live site directly — no browser, just requests — item by item:

the search page answers 200 and is HTML;
every param, range, slug and segment filter builds one URL with a representative value and answers 200 without redirecting off-origin;
the result count and at least one row can be read off the search page, the same way a real conversation would read them;
declared facet selectors match at least one group;
every sort URL answers 200.

A page that answers with a login wall or a 403 comes back unverifiable, not failed — some sites require a session for search, and that isn't the map's fault. The same checks run on demand from Setup's "Does it work on your site" step, or any time you suspect something changed.

Reading a run

Each run is one document: an overall state, how many items failed, how many came back unverifiable, and the per-item list — kind, name, status, a plain-English detail, the URL that was tried, and how long it took.

The Checks screen showing the latest run as Failing checks with one failing item, and a run history list below it with an earlier Healthy run — Checks on the demo tenant: the latest run failed one item out of eight; the run before it was clean.

A single check run expanded, showing each item — search, two filters, count, rows, and a failed facets item — with its status, detail sentence and the URL that was tried — Expanded: search, both filters, the count and the rows all passed; the facet group didn't match anything on this run. Every item links to the exact URL that was tried.

What "unverifiable" means, concretely

It means the check couldn't tell either way — not that the filter is broken. The most common cause is a search page that needs a login before it shows results; the map isn't wrong, the check simply has no session to test with. Treat a failing item and an unverifiable one differently: a failure is something to fix in the map or on the site, an unverifiable item is something to go and look at by hand.

What Gerry does when a check would have failed live

The nightly check exists so you find out from the panel, not from a visitor. Independently of the schedule, if a filter genuinely can't be applied at conversation time, Gerry says so — "I can't do that on this page" — rather than guessing or failing silently.

← Languages & the greeting Insights →

Questions: hello@heygerry.io. These pages describe what is built today; nothing here is a promise about what is not.