Breakpoints

Breakpoints pause a matching request or response mid-flight so you can edit it, then decide what happens next.

Setting a breakpoint

Select Breakpoints in the sidebar and add a pattern to either list — the same pattern syntax as every other list:

Pause on Request — matching requests pause before they reach the server. You can edit the method, the path, the headers, and the body.
Pause on Response — matching responses pause before they reach the app. You can edit the status code, the headers, and the body.

When something pauses

A paused request is holding a real connection open, so HTTPGlass makes sure you notice:

The Dock icon bounces.
Breakpoints in the sidebar shows an orange count of paused messages.
The row in the traffic table reads Paused, and the inspector points you to Breakpoints.

In Breakpoints, under Pending, each paused message is an editor card. From there:

Resume — send it on, with your edits applied
Drop — end the connection without sending anything

Timeout

By default a paused message resumes unchanged after 120 seconds, so a flow can’t be left hanging if you walk away. Change the number under Timeout, or switch on Wait until I resume to wait until you resume, drop, or stop capturing.

Where it sits among the other tools

A breakpoint is the last stop before the wire. Map Remote, Rewrite, and scripts have all run by the time a message pauses, so what you see in the editor is what those tools produced. For an edit you want made every time, use Rewrite or a script instead and leave breakpoints for the one-off.

HTTP/2

Pausing works on HTTP/1.1. A host with a breakpoint pattern is negotiated down to HTTP/1.1 automatically, so this only matters if you’re comparing protocols — other hosts keep HTTP/2.