The broken booking form that led to Nekai Pulse

The broken booking form that led to Nekai Pulse

Pulse started because of a missing phone number field.

I’d built a website for a local sports massage business. Nothing particularly unusual: WordPress, a booking system, online appointments, the usual setup. I’d tested it, the site was live, and customers were using it.

Then one day we discovered that, on some mobile devices, an important field in the booking process simply wasn’t appearing.

The website was online. The server was responding. The booking page loaded. Most traditional uptime monitoring would have looked at the site and said everything was fine.

It wasn’t.

A customer trying to make a booking could get partway through the process and hit something that simply didn’t work properly. From the business owner’s perspective, that’s much worse than a website being completely offline. If the whole site is down, somebody tends to notice. If one field, button, script or step in a booking journey quietly breaks, it can sit there costing you customers without anybody knowing.

That was the problem that led me to build Pulse.

“Your website is up” isn’t enough

I started looking at the monitoring tools that already existed.

There are plenty of very good ones. They can ping a URL every few minutes, check response times, monitor SSL certificates and alert you when a server stops responding.

But that wasn’t really the problem I had experienced.

I didn’t just want to know whether a website responded with HTTP 200.

I wanted to know whether the website actually worked.

Could a visitor load the important pages? Was the content that should be there actually present? Did the JavaScript application load properly? Could somebody click the booking button, choose an appointment and progress through the booking journey?

Those are very different questions.

So I started building a monitoring system around them.

What Pulse actually does

At its simplest, Pulse watches the parts of a website that matter to the business behind it.

Basic monitoring regularly checks important pages, their availability and the content that should appear on them. Pulse also watches things like SSL and domain health. If something goes wrong, it records what it saw and can retain the HTML from the failed page so there’s evidence of what was happening at the time.

But the part I found much more interesting was browser journey monitoring.

Pulse can launch a real browser and behave more like an actual visitor.

Instead of asking:

“Did the booking page return a successful response?”

it can ask:

“Can I open the website, click Book, navigate through the booking system, select the things a customer needs to select and actually reach the next stage?”

That distinction is basically the reason Pulse exists.

A server can be perfectly healthy while the thing that makes the website valuable is completely broken.

For a brochure website, that might not matter very much.

For a massage clinic taking bookings, a restaurant accepting reservations, a tradesperson relying on enquiries or an ecommerce business relying on checkout, it matters a lot.

Those journeys are where the money is made.

I wanted it to be something normal businesses could use

There was another problem with the tools I found: a lot of synthetic monitoring software feels like infrastructure software.

That makes sense. Historically, it has largely been built for developers, operations teams and larger organisations.

But the person who loses money when a booking system breaks might be a massage therapist.

Or a restaurant owner.

Or someone running a small agency responsible for twenty client websites.

They shouldn’t need to understand Playwright scripts, synthetic transactions, status codes or observability platforms just to answer a very simple question:

Is my website working properly right now?

That has influenced almost every decision I’ve made while building Pulse.

I want the interface to be calm and obvious. I want failures to explain what actually went wrong rather than dumping technical noise onto somebody. I want setup to become as close to effortless as I can make it.

Underneath, Pulse can do fairly technical things.

The person using it shouldn’t have to.

Going further than monitoring

The next logical step is something I’ve wanted Pulse to do since fairly early in development.

There is ultimately only one completely convincing way to prove that a booking or enquiry system works:

Use it.

So Pulse is being built to go beyond simply reaching the final stage of important website journeys.

For supported systems, it will actually submit forms and make test bookings, verify that the expected confirmation arrives, and then clean up after itself.

That means Pulse can eventually answer a much stronger question than “does the booking form appear to work?”

It can answer:

“Could a customer actually book with me?”

That is where I think this becomes particularly useful.

A small problem that revealed a bigger one

The funny thing is that Pulse wasn’t the product I originally set out to build.

It came from maintaining a real website and encountering a very mundane problem.

One field disappeared.

But that exposed a gap I hadn’t really thought about before.

Businesses increasingly depend on their websites to generate revenue, yet many have no idea whether those websites are actually functioning from a customer’s perspective at any given moment.

They usually find out when somebody complains.

And the customers who encounter a broken website don’t always complain.

They leave.

Pulse exists to catch those problems first.

Not just to tell you that your server is alive, but to check on the agreed schedule the pages, buttons, forms and journeys that your customers actually depend on.

The goal is simple:

Your website should be tested like a customer uses it.

That’s why I built Pulse.