Website Up but Not Working? What to Check

The home page loads, your monitor says everything is fine, and a customer still emails to say they can't check out, log in, or submit a form. A website that's up but not working is one of the most frustrating problems to chase, because simple checks miss it: they look at the home page, the home page responds, and nobody finds out.

Here's why it happens, how to find the broken piece, and what to monitor so you hear about it before your customers do.

Why a site can fail partially

A website isn't a single page. Each section depends on different moving parts, and any of them can fail on its own:

• A broken template or plugin on one page type: product pages, the blog, or search.
• A partially failing database: cached pages look fine, while pages that need fresh data throw errors.
• A third-party service outage: the payment processor, a map, a booking system, or an API a section relies on.
• A cache hiding the outage: the CDN keeps serving the saved home page while the origin server behind it is down.
• Bad redirects after a migration: old URLs that lead to a 404 or a redirect loop.
• JavaScript errors in the browser: the HTML arrives fine, but the button or form does nothing.
• Forms that submit but never arrive, because the server can't send email.

How to diagnose it, step by step

1. Reproduce it with the exact URL. Ask the customer for the link and open it in a private window, with no session or browser cache.
2. Check that page's status code. A 500 or 503 points to the server; a 404 points to a URL or redirect; a 200 with a broken page points to the template or JavaScript.
3. Follow the redirects with the redirect checker to see where each hop actually goes.
4. Check whether the response came from cache. CDN headers usually say whether a response was served from their cache. If the home page is cached and everything else fails, the problem is at the origin.
5. Open the browser console (F12) and look for errors in red. If there are JavaScript errors, the HTML may be fine and the failure is in the browser.
6. Read the server error log for the time the customer saw the problem.
7. Review what changed last: an update, a new plugin, a migration, or a change at a third-party service.

What to monitor

Watching only the home page is exactly why these failures go unnoticed. A few ideas:

• Several URLs, not one. The pages that make money or get the most use: a product page, the contact page, the booking flow.
• Text that only appears when the page works. A keyword monitor notices when the button or product name disappears, even if the page returns 200.
• The expected status code. If a page should return 200, anything else counts as a failure.
• The APIs you depend on, with an API monitor that checks the method, headers, and expected status code.
• At least one URL that bypasses the cache, so a server outage doesn't stay hidden behind the CDN.

What an external monitor can't see

A monitor like MonitoraWeb checks each URL from the outside, from a single location, without a browser:

• It doesn't run JavaScript, so it can't see what a script renders after the page loads.
• It doesn't log in, fill in forms, or make purchases.
• It can't tell whether a form's email arrived.

For those, test your forms and checkout periodically, or have someone on the team click through the site after every significant change. What it does do, and how, is covered in website uptime monitoring.

Frequently asked questions

Why does my monitor say the site is fine when a page is broken?

Most likely it only watches the home page. Add monitors for your important pages, each with a keyword check.

How can I tell whether the cache is involved?

Look at the response headers: CDNs usually say whether a response came from their cache. If the home page is cached and everything else fails, the origin is down.

Can an external monitor catch JavaScript errors?

No. It sees the HTML the server sends, not what the browser does afterward. Check the browser console for those.

Which pages should I monitor besides the home page?

The ones that drive revenue or leads: a product page, the contact page, bookings, and the APIs they depend on.

Can it check that a form works?

It can confirm the form page loads and shows the form, but it doesn't submit it or confirm that the email arrives.