Skip to content
easycaptcha.to

Latency analysis

Queue wait, solve time, and observed latency are different

Break completion time into admission, remote work, observation, and application stages before deciding which scheduling change helped.

By the easycaptcha team · Published

Reading map for Queue wait, solve time, and observed latency are different: Submission; Remote work + observation; Application action.
An illustrated reading map of the considerations discussed below.View full-size illustration

A stopwatch around a client method may include serialization, network transport, queue wait, solving, a held response, and response parsing. A stopwatch around the whole browser task adds answer application and final submission. Neither is automatically the solver’s own work time.

Measurement clocks

Document the event pair defining each duration. If the remote service does not expose a stage timestamp, mark that stage unobserved instead of deriving a precise internal time from a client guess.

Keep a simple event record

Event pair Possible interpretation
Client start to accepted response Submission and transport observation
Accepted task to terminal observation Waiting, work, and lookup delay
Result observed to action submitted Application integration delay
Action submitted to known receipt Final operation latency

These are proposed client-observable stages. Their names should not imply server internals the dataset does not actually expose.

Attribute improvements carefully

A faster polling interval can reduce the delay between remote completion and local observation. It does not show that the remote solver became faster. Higher queue priority may change waiting behavior without changing image recognition time.

Burst admission and fast priority are also different controls. Enabling both while changing the local observer makes it difficult to isolate which change affected which clock. Run a controlled trial with stable task families and modes.

Report distributions and missing observations

Show a median and a meaningful higher percentile where sample size supports it, alongside sample counts and unknown outcomes. Averages alone can hide the few attempts that dominate visitor frustration.

Include slow tasks in the cohort even when the user-facing deadline stopped waiting. Reconcile them separately rather than making a shorter timeout appear to improve latency by removing hard cases.

Mode integration explains what scheduling controls do, observation lag isolates client delay, and tail latency develops a report that distinguishes common fast completion from rare, costly waits.

Frequently asked questions

Can client timestamps reveal exact queue and solve time?

Not necessarily. A submission-to-result interval can include remote work, transport, and observation delays. Label only the stages you can measure.

Which timestamps are useful for a task integration?

Record submission, accepted response, terminal observation, result application, and known verification receipt where available.

How can easycaptcha fit into my integration tests?

Use the documented recognition or token API for the hCaptcha stage, preserve task IDs, and inspect terminal results. Measure verifier acceptance and application completion separately from job completion.

Try easycaptcha

Test your hCaptcha workflow with easycaptcha

Measure easycaptcha job timing from submission through result application using clearly defined clocks.

Use the recognition and token API to exercise your integration, inspect job results, and report observed acceptance. Get started with typed Python and JavaScript SDKs.