Why it works?
Because a website can be online — and still not work
The server responds. The homepage loads. Everything looks fine. Except the contact form doesn’t send anything. The button doesn’t lead anywhere. The CAPTCHA blocks real visitors. Login ends in an error. Or the page returns a status of 200 OK, even though all the visitor sees is an error message. The most costly website failures often aren’t visible. They show up as silence.
A contact form is never just a few fields and a button
For a form message to actually reach the right inbox, the entire chain has to work correctly:
- The visitor has to fill out the form correctly.
- Validation has to clearly tell them what's missing, if anything.
- JavaScript must not fail during submission.
- The CAPTCHA has to stop bots, but let a human through.
- The form or plugin has to process every submitted field.
- The server or email service has to accept the message.
- The API key has to be valid and the account active.
- The sending domain has to be configured correctly.
- Spam filters have to let the message through.
- The message actually has to arrive in the right inbox.
Any single link in that chain can fail on its own. An API key can be revoked or compromised. A paid account can run out of credit. A plugin update can change its behavior. The CAPTCHA can be misconfigured. An email template can forget one of the fields, so the message arrives — just without the phone number, the address, or the message itself. And the form can still tell the visitor: “Your message has been sent.”
The form is just one example
Other parts of a website can fail just as quietly:
- a prominent button has no link or action;
- a JavaScript error blocks a menu, filter, or checkout;
- a menu covers the text on mobile;
- an image, font, or important network request fails to load;
- a visitor can't log in;
- the cart works, but there's no way from the cart to checkout;
- after a website change, something you seemingly never touched stops working;
- an error page gets sent with a status of
200 OK, so a standard uptime monitor doesn't notice a thing.
“The website is up” doesn’t mean “the website works”
A standard uptime monitor asks: Does the server respond? Jede asks: Can the visitor actually do what they came to the website to do? That's why Jede doesn't just crawl a website like a technical bot checking a server status code. It opens pages in a real browser and watches what actually happens as they load. For example, it checks for:
- pages that don't load correctly;
- broken images and other resources;
- failed network requests;
- JavaScript and console errors;
- controls that look active but don't do anything.
Because nobody wants to check a website by hand every day
Sure, you can regularly open each of your websites, click through the important pages, submit forms, and check the browser console. Once. Maybe twice. Then other work comes up, and checking the website gets pushed to later.
Jede does this tedious, repetitive work for you. When everything is fine, it stays quiet. When something important stops working, it lets you know. Jede doesn't replace a developer, but it tells you exactly when you actually need one.
Don't wait for a customer to reach you some other way
The worst way to find out your website is broken is a message that says: "I tried to contact you through the form, but it didn't work." What's worse is when nobody sends you that message at all.
I sleep soundly. The website works.