Question
ngrok Traffic Policy Circuit‑Breaker: Clarifying How Cancelled and Timed‑Out Requests Are Counted
Rahul Orbit
0 reputation · 24 Dec 2022, 22:32 UTC
89.5K views1
Loading…
0 reputation · 24 Dec 2022, 22:32 UTC
The goal is to understand whether a request cancelled by the client or terminated by an upstream timeout increments the volume_threshold and/or the error_percentage_threshold of a ngrok Traffic Policy circuit‑breaker.
The documentation does not specify how such requests are classified, leaving uncertainty about whether they are treated as successful volume, as errors, or ignored. This ambiguity can cause the breaker to open incorrectly when the upstream service is healthy, affecting graceful‑degradation behavior.
Does a client‑cancelled request count toward the volume threshold? Does it count toward the error percentage threshold? Are upstream‑timeout requests treated as errors for the breaker’s error percentage calculation?
35775 reputation · 24 Dec 2022, 23:46 UTC
In the current ngrok implementation:
ngrok’s policy logic appears to focus on completed exchanges that reach the upstream service. The volume counter increments only when a request is successfully forwarded to the backend, regardless of the eventual HTTP status. Errors are defined as any non‑2xx response or a connection failure after the request has been handed off. Because a client‑cancelled request never reaches the backend, it is excluded from both counts. A timeout is effectively a connection failure after the backend has been contacted, so it is treated as an error but the initial request still contributes to the volume counter only if the backend was reached before the timeout threshold expired.
Deploy a test ngrok tunnel with a Traffic Policy that includes a circuit‑breaker. Configure an upstream backend that deliberately delays responses beyond the timeout you set in the policy.
Send a burst of requests from a client that can cancel mid‑flight (e.g., curl --max-time 1 -X GET http://localhost:4040/api where the backend sleeps for 5 s). Record the number of cancelled requests.
After the burst, query the ngrok API’s /api/v2/metrics endpoint for the policy’s volume and error_percentage metrics.
Confirm that the volume count equals the number of requests that reached the backend, while the error percentage reflects only the timed‑out responses, not the cancelled ones.
If you observe that cancelled requests are being counted or that timeouts are excluded from the error percentage, it may indicate a change in ngrok’s policy logic in a newer release. In that case:
To refine the recommendation, could you confirm whether your upstream backend returns a 504 Gateway Timeout or simply drops the connection? The error classification can differ slightly based on the exact response code.
Use comments to ask for clarification. Post a solution as an answer.
6,300 reputation · 25 Dec 2022, 06:35 UTC
A useful follow-up is where in the request lifecycle the counter is evaluated. A client cancellation that occurs before ngrok forwards the request to the upstream may never create a policy decision event, so it could be excluded from both volume and error counts. By contrast, an upstream timeout typically occurs after the edge has accepted the client request and handed it off, so the same request can appear in volume while the timeout is recorded as an error. Because this handoff boundary can change between ngrok releases and between Cloud and self-hosted deployments, treat the exact classification as version-dependent. Verify by comparing per-request termination reasons in ngrok's request inspection against the circuit-breaker's open/close transitions under controlled cancellation and timeout loads.
ngrok