Count accepted jobs that miss their completion deadline

Give the operation a durable identity

Create a job or operation record when the service accepts valid work. Record its accepted time and the deadline relevant to the promised outcome.

Carry that identity through retries and worker attempts. A retry is another attempt at the same operation, not automatically another customer request in the denominator.

Define how cancellation and invalid input affect eligibility. Keep that policy explicit so reporting does not change according to whichever status is easiest to count.

Record terminal outcomes and overdue work

Save completion or failure against the operation. Independently inspect accepted operations whose deadlines have passed without the required outcome.

SELECT
  COUNT(*) AS eligible_operations,
  COUNT(*) FILTER (
    WHERE completed_at IS NOT NULL
      AND completed_at <= deadline_at
      AND outcome = 'succeeded'
  ) AS good_operations
FROM operations
WHERE accepted_at >= :window_start
  AND accepted_at < :window_end
  AND deadline_at <= :measurement_time
  AND eligible = TRUE;

This illustrative query evaluates matured operations so recently accepted work is not prematurely labelled late. The reporting window and maturity delay need to be stated clearly. Production storage and indexing should match the expected volume.

Preserve the history of a missed deadline

A job that eventually succeeds after its deadline should remain a missed timely outcome for that measurement. Updating its status to succeeded must not erase the delay the user experienced.

Keep eventual completion useful as a separate operational measure. It helps explain recovery and outstanding work without rewriting the original service result.

Test clock handling and timestamp sources. Use a consistent time basis and avoid comparing unsynchronised worker clocks without an appropriate design.

Validate against known jobs

Create synthetic operations that finish early, finish late, fail, retry and never finish. Calculate their expected contribution independently and compare it with the query.

Then inspect the dashboard during a worker outage. The indicator should reveal overdue accepted work even when no worker is alive to emit failure metrics.

Connect the measure to a runbook that identifies the affected backlog and safe recovery path. A percentage is useful when the operator can trace it back to the operations that need attention.