CATAPULTAI WORK
Start a project

Custom Software & SaaS

Show Progress and Cancellation for Long Jobs

Create a durable job with a status page, ownership, timestamps and clear terminal states. Report meaningful progress only when it can be measured. Treat cancellation as a request with defined stopping points, and explain partial work instead of promising that every action can be undone.

An import, export or document conversion can take longer than a normal page request. A spinner gives little help if the tab closes or work becomes stuck. Treat long-running work as a persistent job that the user can revisit, inspect and, where safe, stop.

Related service: Custom software development
AT-A-GLANCE FLOWMake background work visible
  1. 01Validate and accept the job.
  2. 02Show its queued or running state.
  3. 03Report measured progress and recent activity.
  4. 04Honor cancellation at safe boundaries.
  5. 05Present the result or a useful failure summary.

SECTION 01

Replace the endless spinner with a job record

A useful job model distinguishes queued, running, completed, failed and cancelled work, with cancellation requested when stopping is not immediate. Azure's asynchronous request-reply pattern describes accepting work separately from its later status. The browser should be able to recover that status after a refresh without submitting a second job.

Progress can be items processed out of a known total, or a named stage when the total is unknown. Avoid a fabricated percentage that reaches 99 percent and waits indefinitely. Record the latest activity time and define when an operator should investigate. The status resource and eventual download still require authorization, even if their identifiers are difficult to guess.

SECTION 02

Illustrative example: a large supplier catalogue import

Imagine a supplier catalogue containing 12,000 items. The job validates the file, checks matches and then applies approved changes. The user requests cancellation during validation. Stopping before writes is straightforward; stopping after 4,000 updates requires a clear account of which changes already happened.

For this hypothetical workflow, the business chooses staged validation followed by an explicit apply step. Cancellation before applying discards the staged proposal. During application, stopping occurs between safe batches and produces a result listing completed and unprocessed items. That is not identical to reversing every update, particularly if later workflows have already used the changed records.

SECTION 03

Choose the smallest useful control surface

The first release can support a few job types and a simple history table rather than a universal task orchestrator. An existing queue or platform job service may provide execution machinery, but the agency still needs to design customer-facing states and support ownership. Compensation guidance from Azure helps distinguish a later corrective action from ordinary rollback.

Test refreshing the page, closing the tab, worker failure, duplicate submission, permission removal and cancellation just before completion. The outcome should be one coherent terminal state, not simultaneously cancelled and successful. Confirm how results expire and who can restart failed work. For partial changes, require an item-level summary and a documented recovery decision before an operator launches another full run.

SECTION 04

Frequently asked questions

Does a cancel button instantly stop the work?

Not necessarily. It requests a stop at a safe point. The interface should say when cancellation is pending and disclose any work already committed.

Must every job show a percentage?

No. Stages and recent activity are more honest when the total work is unknown. Use percentages only when they represent a meaningful measured quantity.

Can users leave the page while it runs?

That should be an explicit requirement. A durable job can continue independently and expose its status when the user returns, subject to current access permissions.

PRIMARY REFERENCES

Sources and further reading

These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.

ABOUT THE AUTHOR

Catapult AI Work Technical Team

Catapult AI Work builds websites, business software, AI automations, and mobile apps. We write these guides to help business owners compare options and prepare project requirements.

EDITORIAL METHOD

About this guide

We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.

Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.

Read the editorial policy

PLAN YOUR IMPLEMENTATION

Discuss the task you want your software to handle

Share your current workflow, the people involved and the outcome you need. We can discuss a focused implementation and its responsibilities. Contact us for pricing.

Discuss your project