Skip to content
Recuro Docs

Creating a Queue

This guide walks you through creating a queue — a named container for one-off HTTP jobs with shared retry, timeout, and assertion settings.

When to use queues vs. crons

Use a cron when…Use a queue when…
You need recurring execution on a scheduleYou need to fire a one-off HTTP request
The schedule is the same every timeThe timing depends on an event in your app
Examples: health checks, nightly syncs, hourly reportsExamples: webhook delivery, delayed emails, post-signup tasks

Via the dashboard

  1. Navigate to Queues in the sidebar
  2. Click New Queue
  3. Fill in the form:
    • Name: A descriptive name (e.g., “webhooks”, “notifications”, “email-delivery”)
  4. Optionally configure:
    • Timeout: HTTP request timeout in seconds (1-300, default: 30)
    • Retries Enabled: Whether to retry failed jobs (default: on)
    • Retry Delays: Array of wait times in seconds between retries (default: 60, 1800, 10800)
    • Success Assertions: Response conditions all jobs must satisfy
    • Alerts Enabled: Whether to send notifications on failures
    • Max Parallelism: Limit concurrent processing (leave empty for unlimited)
    • DLQ Retention: Days to keep dead-lettered jobs (3, 7, 14, or 30)
  5. Click Create

Via the API (auto-creation)

Queues are created automatically when you push a job with a new queue name:

Terminal window
curl -X POST https://app.recurohq.com/api/jobs \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "queue": "webhooks",
    "url": "https://partner.example.com/webhook",
    "method": "POST",
    "payload": { "event": "order.completed" }
  }'

If the queue webhooks does not exist, it is created with default settings. You can then customize it from the dashboard.

Configuring retries

The default retry delays are [60, 1800, 10800] — 1 minute, 30 minutes, 3 hours. To customize:

  1. Go to Queues > [queue] > Edit
  2. Enable Retries
  3. Set the retry delays — each value is the number of seconds to wait before the next attempt
  4. Save

The number of retry attempts equals the number of delay values. For example, [30, 300, 3600] means 3 retries: after 30 seconds, after 5 minutes, and after 1 hour.

You can configure up to 10 retry delays, with each value between 1 and 86,400 seconds (24 hours).

Configuring parallelism

If your target endpoint is rate-limited, set Max Parallelism to prevent overwhelming it:

  1. Go to Queues > [queue] > Edit
  2. Set Max Parallelism (e.g., 5 for an endpoint that allows 5 concurrent requests)
  3. Save

When the limit is reached, additional ready jobs wait until a processing slot opens.

Configuring success assertions

Assertions apply to every job in the queue. To add them:

  1. Go to Queues > [queue] > Edit
  2. Click Add Assertion
  3. Choose a type and enter a value:
TypeExampleEffect
status_code_equals200Job fails if your endpoint returns anything other than 200
body_contains"success"Job fails if the response body does not contain “success”
response_time_under_ms3000Job fails if the endpoint takes more than 3 seconds

See Cron Schedules > Success assertions for all assertion types.

Viewing queue details

Navigate to Queues > [queue] to see:

  • Queue configuration — Timeout, retry delays, parallelism, DLQ retention, assertions
  • Job stats — Total jobs, completed, failed, pending, dead-lettered
  • Response time stats — Average and percentile response times

Filtering queues

On the Queues page, use the controls to filter:

  • Status filter — All, Active, or Inactive
  • Search — Find queues by name

Editing a queue

Navigate to Queues > [queue] > Edit to change any setting. Changes apply to new jobs — jobs already in-flight continue with their original settings.

Pausing a queue

Set Active to off on the edit page, or toggle it from the queue list. Paused queues stop processing new jobs but jobs already in-flight complete normally.

Deleting a queue

Navigate to Queues > [queue] and click Delete. This permanently removes the queue and all its jobs.

Next steps