Skip to content
Felix Schumann
Editorial illustration: Long-running AI jobs: Show progress without pretending the work is done
Journal / 20

Long-running AI jobs: Show progress without pretending the work is done

Felix Schumann·

Research runs for several minutes. A spinner moves, but nobody knows whether work continues or the request has been lost. For custom AI workflows, this intermediate state is part of the product. My content platform connects several steps through production. For such work I would design progress and cancellation as explicit functions.

Research checked: 2026-09-11 · Cover: AI-generated illustration

Accepted does not mean completed

HTTP 202 Accepted confirms that a request was accepted, not that processing succeeded. MDN explicitly describes this distinction. After starting, the interface should therefore display a job with a verifiable state.

For an example workflow I would distinguish queued, processing, review and complete. Failure has its own state. People can then tell whether capacity is unavailable, content is being processed or a question remains open.

MDN: 202 Accepted ↗

Tie progress to actual work

If six of ten known documents are processed, that subset can be reported. When the number of remaining steps is unknown, I would avoid inventing precise percentages. “Evaluating sources” is more useful than a bar stuck at 99 percent.

Each job needs a stable identifier and an update timestamp. Reloading should recover the same job. The browser becomes a view of the work rather than its only memory.

The decision at a glance

  1. 01AcceptedJob durably recorded
  2. 02ProcessingShow verified progress
  3. 03CompleteVerify the destination outcome
Our schematic illustration of the proposed approach, not measured data.

Define what cancellation actually does

AbortController can abort certain web requests and associated processing. It does not automatically terminate a server job that has already started. That requires an application-level cancellation request and acknowledgement from the worker.

I would distinguish work with no external effect yet from partially completed actions. Closing a window does not undo a publication that already happened. The interface needs to show which steps stopped and which effects remain.

MDN: AbortController ↗

Test through interruptions

Acceptance should close the page during a job, reopen it and request cancellation during an active step. The persisted state must match the actual work afterwards. Clicking start again must not silently create a second job.

If your team waits on long-running AI tasks, I can add a clear job view with traceable states. We would first identify which steps can be measured and which actions can safely be interrupted.

Sources and further reading