Holiday video drop at 9am: submit by when? The Sume 90-minute deadline

A Format run is force-finalized as failed 90 minutes after creation, so a 9am drop needs the batch submitted well before 7:30, with headroom for retries.

3 min readSume
All posts

A single Sume Format run has a hard deadline: expires_at is 90 minutes after created_at, or earlier when the run goes quiet. Past it, Sume finalizes the run as failed. That gives you the latest safe submit time for a launch.

Work backwards

For a 9:00 drop, a lone run submitted at 7:30 could still fail at the deadline with no time to react. Build in one retry: a failed run needs a new create, which has its own 90 minutes. A practical rule is to submit the night before, and use the morning only for re-runs.

For a queue

  • The 90 minutes applies to each child run, from its own created_at, not to the queue.
  • A queued item has not started its clock; a child only gets a run_id once dispatched.
  • Create already fills the window, so with concurrency: 16 the first 16 are in flight on the 202 receipt.

Poll cheaply

Read the queue, not every child, while you wait. Polling spends the read budget, which is 40 times the write budget on each plan. Branch on counts.failed when the queue turns completed, and re-queue only failed rows with a fresh Idempotency-Key.

curl -sS "https://api.sume.com/v1/format-run-queues/$QUEUE_ID" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq '.data | {status, counts}'

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume