Rotor can notify you when a job fails after all retry attempts are exhausted. Alerts fire per workspace, not per queue — one configuration covers all your queues.

Configure alerts

Go to Dashboard → Settings → Notifications.

You can configure either or both:

  • Email — enter any email address. Alerts are sent from [email protected].
  • Slack incoming webhook — paste a webhook URL from your Slack app. Messages arrive as a formatted Block Kit card.

Save. That's it.

What triggers an alert

Alerts fire on terminal failure only — when a job exhausts all retry attempts and moves to failed state. They do not fire on intermediate retry attempts.

If a queue has attempts: 3 and a job fails on attempt 1 and 2 (and retries), no alert is sent. The alert fires when attempt 3 fails.

Slack message format

❌ Job failed in `enrichment`

Reason: Connection timeout after 30s
Job ID: job_abc123
Queue: enrichment

[View run →]

The "View run" link opens the job directly in your Rotor dashboard.

Create a Slack incoming webhook

  1. Go to api.slack.com/apps and create or open an app.
  2. Enable Incoming Webhooks under Features.
  3. Click Add New Webhook to Workspace and choose a channel.
  4. Copy the https://hooks.slack.com/services/... URL.
  5. Paste it into Settings → Notifications → Slack Incoming Webhook.
Note

The Slack webhook URL must start with https://hooks.slack.com/. Rotor validates this on save and rejects anything else.

Email alerts

Email alerts are sent from [email protected] with the subject:

Job failed: {jobName} in queue {queueName}

The body includes the queue name, job ID, failure reason, and a direct link to the run in your dashboard.

Add [email protected] to your contacts to prevent spam filtering.

Testing alerts

The easiest way to test: enqueue a job to a queue whose callback URL returns a 5xx response, with attempts: 1.

await rotor.jobs.enqueue("test-queue", {
  payload: { test: true },
});

With attempts: 1, the first failure is terminal and triggers the alert immediately.

Tip

Failure alerts are workspace-level. If you want different channels for different queues, that's a future feature — today it's one config per workspace.