Aglet

Triage job claim delay before measuring runtime

A job that appears slow may have spent most of its lifetime waiting before any worker claimed it. Triage one ready job from enqueue through start and compare it with a quiet-pool and busy-pool control. Keep pre-execution wait separate from runtime so the next owner investigates the right boundary.

Establish what is happening

  1. Mark the pre-execution timeline

    Record enqueue, ready, first poll, lock attempt, claim, start, and terminal times for the job. Include queue, worker pool, eligibility, and any retry or lease metadata. Preserve a missing timestamp as a gap rather than replacing it with total age.

  2. Compare quiet and busy pools

    Select a job that claims when workers are quiet and another with the same shape during a busy interval. Note worker availability and queue depth at each poll. If both claim promptly but execute slowly, move the scope to runtime rather than claim delay.

  3. Find the first waiting boundary

    Inspect poll cadence, queue routing, lock ownership, and worker assignment around the first eligible moment. Identify whether the job was not seen, could not claim, or waited for a worker that was already occupied. Keep lock contention distinct from ordinary capacity wait.

What to carry forward

Return ready-to-start timestamps, queue and worker context, lock evidence, first waiting boundary, and a quiet or busy comparison. Classify the scope as polling, routing, lock contention, worker capacity, or runtime. Keep claim delay unproven when ready or eligibility time is absent.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow