What is there to fix when nothing crashes?

The problems that throw no error

Controls that do nothing

A button with no handler, or one covered by a transparent overlay. The click is swallowed and nothing is logged.

Requests that fail without a message

The API returns an error and the code handles it by doing nothing. The screen still looks saved.

Work with no acknowledgment

A request is in flight and nothing on screen shows it. People click again, and a checkout form can send the order twice.

Stuck states

A spinner that never stops after the network goes idle, a dialog that ignores Escape and outside clicks, or a page whose scroll stays locked after a modal closes.

Fields that drop input

A field that looks editable but discards what is typed into it.

Forms people give up on

A form submitted twice with no error in between, which usually means nothing confirmed the first submit worked. Or a form started and abandoned.

People who cannot find their way

Sessions that bounce between two pages, or click across many elements and never submit anything. These are rarely code defects. They show a page that does not answer the question people came with.

Probie looks for all of these, and none of the checks needs an exception to fire. Most run on behavior events the SDK records in real sessions. Fields that drop input are found by the free inspection, which types into the fields it visits.

Why these are harder to fix

An exception comes with its location. A silent failure comes with a sequence of events, and the fix depends on reading that sequence correctly.

• There is no stack trace. The evidence is what the person did: the clicks, the requests, and what happened on screen afterwards.
• Intent matters: three fast clicks are normal on a quantity stepper and a problem on a submit button.
• The fix usually lives in UI code: a missing pending state, an unhandled failure path, an overlay with the wrong stacking order.
• The regression test has to reproduce a behavior, not an exception. It clicks the control and asserts what should happen next.

What a fix looks like

Double submit

Disable the submit button while the request is in flight. The test clicks twice and asserts one request.

Failed save with no message

Show the error and keep what the person typed. The test stubs a failing response and asserts the message appears.

Dead button

Wire the handler or fix the overlay. The test clicks the button and asserts the navigation or request.

Stuck spinner

Clear the loading state on every exit path, including errors and timeouts. The test fails the request and asserts the control recovers.

Probie produces fixes like these through the following steps:

• A detector flags a session, and a model reads the session trace to decide whether it shows a real problem.
• Sessions that hit the same problem are grouped into one issue with the evidence attached.
• For projects connected through the GitHub App, a coding agent in an isolated container writes the change and a regression test. A reviewer checks it against acceptance criteria before the pull request opens.
• A person on your team reviews and merges. A behavior baseline per route flags the route if the friction returns.

Probie does not verify individual fixes after merge. The route baseline is the check that the friction stayed gone.

Does this replace error monitoring?

No. Exceptions still need an error tracker, and Seer is a good fit when your problems show up as exceptions. Behavior-based fixing covers the problems an error tracker cannot see. Probie can also take Sentry issues as input, so the two feed the same queue.

Check what your project has today

A free Probie inspection drives a browser through your public pages and reports the problems in this guide that it can reproduce without real users: controls that do nothing, fields that drop input, failed requests the screen never mentions, work with no visible acknowledgment, and slow first responses. It needs no account and no install.

Questions