Skip to main content
Novu retries at several points along the delivery path, and the policy is different at each one. The most important thing to know is that a provider send is attempted once - if SendGrid, Twilio, or FCM rejects the request, Novu records the failure and moves on rather than retrying the send. This page documents each retry layer, the exact attempt counts and backoff, and what recovery options exist when a delivery fails.

​
Retry policy at a glance

​
Channel and provider sends

When a channel step runs, Novu resolves the integration for that channel, renders the content, and makes a single call to the provider. There is no automatic retry, no backoff, and no ceiling, because there is no second attempt. If the provider call throws or returns no message identifier, Novu:
  1. Records an Unexpected provider error execution detail with a Failed status, including the raw provider response.
  2. Emits a messages.failed webhook so your system can react.
  3. Marks the step as failed in the Activity Feed.
  4. Continues to the next step in the workflow. See When a step fails.
This applies to email, SMS, chat, and push. Provider rejections are treated as terminal regardless of the status code - a 429 Too Many Requests or a 503 Service Unavailable from a provider is handled the same way as a 400 Bad Request.
Because provider sends are not retried, a transient provider outage results in permanently undelivered notifications for the affected workflow runs. Subscribe to messages.failed if you need to detect and respond to these.

​
Per-channel details

  • Push sends to every registered device token across the subscriber’s push integrations. If some tokens succeed and others fail, the step is recorded with a Warning status and the workflow continues. The step is only marked failed when every token fails.
  • In-app (Inbox) does not call an external provider, so there is no provider send to retry. The message is stored in Novu and pushed to connected clients over websocket.
  • Email Webhook is the one provider that retries internally. It re-posts to your configured webhook URL up to 3 times with a fixed 30 second delay between attempts before failing the step. This is provider-specific behavior, not the platform policy.

​
There is no automatic provider failover

Novu selects one integration for a channel before the send - the primary integration, or the one specified by payload in override. If that provider fails, Novu does not fall back to another configured integration for the same channel.

​
Bridge endpoint calls

When a workflow is defined with Novu Framework, Novu calls your bridge endpoint to resolve step content. Unlike provider sends, these calls are retried: Retries are triggered for HTTP 408, 429, 500, 503, 504, 521, 522, and 524, and for transient network errors such as ECONNREFUSED, ECONNRESET, ETIMEDOUT, and ENOTFOUND. Other responses, including most 4xx codes, are not retried. Each request has a 5 second timeout. See Retry behavior for the full reference.

​
Outbound webhooks

Webhooks that Novu sends to your endpoints follow a separate, much longer schedule: 8 attempts over roughly 27.5 hours, starting immediately and backing off to a 10 hour ceiling. See Webhook retry schedule.

​
When a step fails

A failed channel step does not stop the workflow. The failure is recorded and the next step is queued and runs normally, so a failed email step is still followed by the SMS step after it. A failed action step - digest, delay, or throttle - stops the run. Every remaining step for that subscriber is canceled and shown as canceled in the Activity Feed, because those later steps depend on a result the action step never produced.

​
FAQs

A provider rejection is usually deterministic - an invalid recipient, a rejected template, a suspended account, or exhausted credits - and retrying it produces the same result while delaying the rest of the workflow. Novu surfaces the provider response in the Activity Feed and through the messages.failed webhook so you can decide what to do with the specific failure.
No. Attempt counts and backoff are fixed at each layer and are not configurable per workflow, step, or integration.
No. A 429 from a provider fails the step like any other provider error. Use the throttle step to limit how often a workflow sends to a subscriber, and check your provider’s own sending limits.
No. Failed steps are recorded in the Activity Feed with the provider error attached, but they are not moved to a queue you can inspect or re-drive. Treat the Activity Feed and the messages.failed webhook as the record of failed deliveries.
Novu marks the step as successful once the provider accepts the request. Downstream delivery status, such as a bounce or a carrier rejection, arrives through provider delivery receipts where supported and is reflected on the message. It does not trigger a retry.