Aglet

Prioritize batch window overruns by collision and recovery risk

A batch that runs past a window can consume capacity meant for the next occurrence or leave a report with no clear completion point. Prioritize the operational consequence and the recoverability of leftover items. A one-time slow run with a durable checkpoint differs from repeated overruns that erase the schedule boundary.

Decide where the work belongs

  1. Rank boundary consequences

    For each overrun, record whether the next run was delayed, overlapped, skipped, or unaffected. Put duplicate processing and stale output ahead of a late finish that remains within an explicit drain policy. Include the work still unowned when the window ended.

  2. Compare batch shapes and rates

    Group occurrences by item count, dependency path, and observed service rate. Compare a healthy window with the same shape and a slower input. Do not treat a large batch as proof of cause until the timeline shows where service or waiting changed.

  3. Choose a bounded action

    Select immediate investigation, a controlled window adjustment, or evidence collection. Name the next run or workload change that should reopen priority. Avoid extending the window blindly when the real issue is a missing checkpoint or an unsafe overlap policy.

What to carry forward

Queue the issue with the exact boundary consequence, leftover recovery state, repeated shape evidence, and next-run risk. Escalate when work crosses into another occurrence without an explicit policy. Otherwise schedule a service-rate or cutoff investigation with a known batch fixture.

Technical background: Celery documentation.

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