How to Detect Broken Buttons on a Website

Broken buttons are easy to miss and expensive to ignore. A page can stay online while the button that drives signup, checkout, or lead generation quietly stops working.

Start your 7-day trial — no credit card, free plan after.

Why broken buttons slip past uptime checks — and how to catch them.

Why broken buttons cause outsized business damage

A broken button is not always obvious in analytics right away. The page still loads, the traffic still arrives, and the campaign may keep running. Meanwhile, visitors can no longer move to the next step.

This happens after releases, style changes, JavaScript issues, CMS edits, and third-party script conflicts. Because the page is technically online, the problem often escapes basic uptime checks.

How to detect broken buttons before customers report them

Start by identifying the buttons tied directly to revenue or lead flow. That could be Add to Cart, Start Free Trial, Request Demo, Submit, Book Now, or Checkout.

Then monitor the page with step-by-step customer actions in a real browser. A journey that clicks the button fails at that step, with a screenshot, if the button disappears, stops responding, or no longer leads to the right outcome.

JavaScript error monitoring is also important because front-end issues often break button behavior without removing the element from the page.

Examples of broken button scenarios

These are common ways a button can fail while the page still looks mostly live.

The button disappears

A design change or CMS update removes the call to action from the visible page.

The button is visible but dead

Users can click it, but nothing happens because a front-end error blocks the action.

The button sends users to the wrong place

A route change or bad link configuration pushes visitors into a broken step.

The next page fails

The button works, but the journey still breaks because the form, cart, or next page does not load correctly.

NorthDuty journey run for an online rental booking: steps 1 to 5 pass, step 6 fails because the availability check returned HTTP 504, with a screenshot showing the booking form's timeout message
A real NorthDuty journey on our demo store: the booking page loaded and every option was selected, but the inventory API behind Check availability returned a 504. Uptime stayed green; the journey failed at the availability step, named the request, and kept the screenshot.

Best practices for monitoring broken buttons

Treat key calls to action as part of your monitoring program, not just your design system.

Which buttons to monitor first — and what to assert after the click

A click that registers proves nothing. Each of these checks is only useful if it asserts on a state that cannot exist unless the button actually worked.

ButtonWhy it earns a checkAssert on
Add to cartThe first step of every order; breaks on variable products and after plugin updatesThe cart count incrementing, or the product appearing in the cart drawer
Checkout / Place orderThe order itself, and the most expensive thing to loseThe order-received page, or the payment step loading with the right total
Start free trial / Sign upNew revenue, and usually the busiest CTA on the siteThe signup form appearing, or the account-created state
Log inEverything behind the account depends on itAn element only a signed-in session renders — not just the redirect
Mobile menu toggleMost traffic is mobile, and this control breaks on its ownThe navigation panel being visible at a phone viewport
Pricing plan selectorThe step between interest and purchaseCheckout loading with the correct plan preselected
Send / Submit on the main formLead flow stops silently when it failsThe exact confirmation text, or the thank-you URL
Download or resource linkGated content and lead magnets fail quietlyA 200 on the file and the expected content type

Why broken buttons get past QA

Buttons are usually tested at the moment they are built, and they usually break later. A plugin update changes the markup, a content editor replaces the block, a tag-manager container adds a script that throws before the click handler binds. None of those events is a deploy, so none of them triggers a test run.

They also break selectively. A button that works on a desktop browser can be unclickable on a phone because an overlay sits on top of it, or dead in Safari because of one unsupported API. Anyone checking the site on their laptop sees a working page, which is exactly why the report usually arrives from a customer instead.

And they look correct while being broken. Visual QA — human or automated — confirms the button is present, the right colour and in the right place. The failure is in behaviour, not appearance, so the only check that finds it is one that clicks and then looks for what should happen next.

Conclusion

Broken buttons are one of the clearest examples of a website failing without going fully offline. They reduce conversions quietly and often go unnoticed until the business feels the drop.

NorthDuty helps teams detect broken buttons by combining change detection, journey monitoring, and website health monitoring on the pages where conversions matter most.

Related NorthDuty Pages

Keep exploring the feature pages and commercial routes connected to this topic.

Related reading

More NorthDuty guides on related website monitoring topics.

Frequently Asked Questions

Short answers that summarize the practical takeaways from this guide.

What should a button check assert on?

The state that only exists if the button worked — the cart count incrementing, the checkout page loading, a signed-in element appearing, the confirmation text. Asserting that the click registered proves nothing, because the click still registers when the handler throws.

Why do broken buttons survive testing?

Because they usually break after the test, not during it: a plugin update changes the markup, an editor replaces the block, a tag-manager script throws before the click handler binds. None of those is a deploy, so nothing re-runs the test.

How do you detect broken buttons on a website?

Use a combination of user journey monitoring, JavaScript error monitoring, and rendered health checks to catch missing buttons, dead clicks, and failed next steps.

Why are broken buttons hard to catch?

Because the page can still look online and mostly normal, so basic uptime checks may not reveal that the key customer action is no longer working.

Which buttons should I monitor first?

Monitor the buttons tied most directly to revenue or lead flow, such as Checkout, Start Trial, Request Demo, Add to Cart, and Submit.

Start monitoring your website with NorthDuty today.

Use NorthDuty to detect broken buttons, missing calls to action, and failed next steps before they quietly reduce conversions on your most important pages.

7 days with Pro features and limits, no credit card — then keep one daily journey on the free plan.