202 Accepted

HTTP Status CodesSuccess (2xx)commonStatus Code: 202Last updated: todayTested on:Google ChromeNode.js v20 LTSJune 2026

The request has been accepted for processing, but the processing has not been completed.

202 Accepted Quick Fix⏱️ Est. Fix Time: 3 minutes

Usually happens because:

  • Queuing heavy computations (like video
  • Asynchronous webhook calls passing messages

🔍 Quick Checklist:

Meaning

The HTTP 202 Accepted status code indicates that the request has been received but not yet acted upon. It is non-committal, meaning that there is no way for the HTTP server to later send an asynchronous response indicating the outcome of the request. It is primarily used for batch or background tasks.

Root Causes

  • Queuing heavy computations (like video transcoding or report generation).
  • Asynchronous webhook calls passing messages to message brokers (RabbitMQ/Kafka).
CauseFrequency
Queuing heavy computations (like video⭐⭐⭐⭐⭐
Asynchronous webhook calls passing messages⭐⭐⭐⭐

Common Mistakes

  • Keeping client HTTP connections open synchronously during 10-minute transcoding tasks (resulting in timeouts).
  • Failing to provide a tracking token or polling endpoint to check status.

How to Fix

1Return a status monitor URL in the response payload so the client can poll for task completeness.
2Ensure client understands that the request may eventually fail during background execution.

Framework-Specific Examples

Triggering Celery-like queues and returning 202 Accepted in Express.

Express Example
app.post('/api/jobs', (req, res) => {
  res.status(202).json({ jobId: 'job-123', status: 'queued' });
});

Server Configuration Examples

Increasing upstream proxy timeouts for asynchronous endpoints.

Nginx Config
proxy_read_timeout 600;

Prevention

  • Implement a robust asynchronous message queue architecture (e.g., Celery, Redis Queue, BullMQ).
  • Setup short connection timeout defaults to force background job delegation.

Frequently Asked Questions (FAQ)

Q: How do client applications track 202 status progress?

Usually, the response payload provides a 'monitorUrl' or job ID. The client sends recurring GET requests to that URL to check if the job is 'processing', 'completed', or 'failed'.

Q: What happens if the background task fails?

Since the connection was already closed with 202, the server status endpoint will simply display 'failed' during client polling.

Q: Is 202 Accepted suitable for sending emails?

Yes, dispatching emails is a classic background job that should return 202 Accepted immediately to prevent blocking UI interactions.

Q: Should a 202 response carry headers like Retry-After?

Yes, servers can include a Retry-After header indicating how many seconds the client should wait before polling the status monitor URL.

Still having this problem?

Didn't solve your problem?

SuggestRequest Error