Website care you can prove.
JourneyPing started from one uncomfortable truth: a site can return a perfect 200 OK while the booking button does nothing, the contact form silently fails, and nobody finds out until the sale is already lost.
A 200 isn’t a working website.
Plain uptime monitors miss the failures that actually cost bookings, the ones only a real browser driving real flows will catch. We built JourneyPing for anyone who is on the hook when a website quietly breaks after an update.
How we work
Check like a visitor
We don’t infer health from a status code. We drive the real flows a customer uses and judge the site on what they’d actually experience.
Evidence over opinion
Every finding comes with proof: a screenshot, a console log, a replay of the failure. Care you can show, not just claim.
Set up by us
We configure your workspace, add your sites and get the first report out. You don’t wire anything up.
How it is run
- Who runs it
- JourneyPing is built and operated by Gerald Labs, a small team. That is why a workspace is set up with you by hand rather than left to a signup form to do alone.
- Where your data lives
- Monitoring results, evidence and account data are stored and processed on managed cloud infrastructure inside the EU. The privacy policy names every processor we use.
- What we do to the sites we watch
- Nothing is installed on them. The scanner names itself JourneyPingBot, visits only once someone has proven they control the domain, and backs off when a server refuses it.
- What we keep, and for how long
- Screenshots expire after ninety days and scan history after a hundred and eighty, and an owner can set both lower. Reports are never removed: they are your client’s record.
What we are building with AI
Coming soonThree pieces of this exist, are tested on every commit, and are switched off for every account. They are here because you should know what is coming toward the product you are weighing up, not because you can use them today. We are not going to give them a date.
A flow described in words
Write what a visitor is trying to do — book the first free slot, get a quote for two rooms — and a model drives a real browser toward it, instead of you listing every click in advance.
A step that moved, not a step that broke
When a journey step cannot find what it is looking for, a model is asked whether the element is gone or has merely been renamed. Renamed heals that run and says so in the report. Your saved check is never rewritten behind your back.
Look for anything broken
A button that walks a site and reports back what it finds, for the moment after a big update when you do not yet know what to check for. Deliberately not a schedule and not an alert: you ask, it looks.
Why we are comfortable building it
What a model is allowed to do is bounded in the code, not in the instructions we give it. It answers in a fixed shape — click, fill, done, or report broken — and no navigation verb exists for it to reach for. A link leaving your client’s site is refused before the click, not after. Reaching a card field ends the run as a pass, because getting that far already proves every step before it. Stored secrets are never sent: the model sees the name of a value, never the value.
See it on a site you actually care about.
We’ll set up a workspace, add a site you look after, and show you the report it produces.