Confirm a queue backend and supervised background processes are available. Decide how each job is identified and whether repeating it could create a duplicate external action.

1. Move the slow operation into a task handler with explicit inputs. Store the job record and required data rather than passing an entire live request object.

2. Submit the task after the application has safely recorded the request. Return a job identifier and a status view instead of making the browser wait for all work.

3. Configure the worker with the production application context and secrets required by the task. Use the supported integration for the chosen queue library.

4. Set timeouts, retry limits and duplicate protection. Separate a temporary provider failure from a permanent validation error.

5. Monitor completion and failures, and restart workers as part of deployment so they load the new application code.

Submit a test job, close the browser and confirm it still completes. Verify a failed job can be investigated without exposing customer content.

Starting an untracked thread inside a request is not a durable replacement for a worker. Process recycling or an application restart can end that work unexpectedly.

• Using a queue for slow exports and notifications
• Handling webhook retries without duplicate actions
• Verifying a deployment with application smoke checks
• Configuring trusted proxy headers for Flask

• Flask Celery integration pattern
• Celery tasks