Skip to main content

Troubleshoot delayed notification dispatch

This page explains why notifications may sometimes be dispatched with a delay, depending on the notification channel (webhooks, email, or SMS).

Overview​

Mambu’s notification system is designed to handle high volumes of messages. To maintain stability and ensure reliable delivery, notifications are placed in a processing queue before being dispatched.

While most notifications are sent almost immediately, delays can happen for different reasons depending on the channel.

Webhooks: delays due to retries or high volume​

Webhook dispatch is available 24/7. However, several factors can lead to a temporary backlog in the queue:

High notification volume​

During periods of exceptionally high notification volume—for example, when a very large number of events are triggered in a very short time—a temporary backlog can form. Notifications will wait longer in the queue before being picked up for dispatch.

Impact of slow or unresponsive endpoints​

If a significant portion of recipient endpoints are slow, unavailable, timing out, or returning retryable non-2XX responses, the system will retry delivery automatically.

  • Automated Retries: The system attempts delivery up to four times in total (one initial attempt and three retries).
  • Increasing Delays: These retries are scheduled with increasing delays between attempts to allow the destination time to recover.
  • Capacity Consumption: While the system manages these automated retries, a portion of the available processing capacity is dedicated to those attempts.

As a result, other notifications in the queue may wait longer before they are picked up for dispatch.

info

During periods of exceptionally high notification volume, if a significant portion of recipient endpoints are slow or unresponsive, the system’s automated retry logic may temporarily consume available processing capacity, leading to a longer wait time for other messages in the queue. This is most visible during significant traffic bursts.

Email and SMS: daily dispatch window​

To ensure predictable delivery timing, Email and SMS notifications are dispatched daily during a window of 09:00 to 18:00, based on your organization’s configured timezone. This dispatch window applies only to Email and SMS; webhooks are not subject to this restriction and continue to be dispatched immediately 24/7.

  • Outside the window: If Email or SMS notifications are generated outside this window, they are held in a queue and picked up for dispatch once the next 09:00 to 18:00 window opens.
  • Resumption delay: If a large volume of notifications accumulates while the window is closed, they are processed in batches when dispatching resumes. This may result in a short additional delay before all messages are sent.

What you should check on your side​

If you experience delays, we recommend investigating your infrastructure and observability data.

Implement a queue-based intake pattern​

To ensure the fastest possible delivery, your webhook receiver should return an HTTP 2xx response as quickly as possible. We recommend the following pattern:

  1. Receive the HTTP call.
  2. Persist or store the event quickly on your side (for example, in a database or message queue).
  3. Return a success status (200 or 202) immediately.
  4. Process the payload asynchronously afterward in a separate worker flow.

Maintain operational visibility​

Observability is essential for understanding your integration's performance. You should have full visibility into:

  • Endpoint Latency: Monitor average and tail (P95/P99) response times.
  • Success and Error Rates: Track spikes in non-2xx responses or timeouts.
  • Incoming Load: Understand the volume of notifications your systems are receiving.

Investigate network and endpoint behavior​

If some notifications arrive successfully while others using the same network path appear to be "missing" or delayed:

  • Review the full request path: Investigate your load balancers, proxies, firewalls, and WAF logs.
  • Correlate timestamps: Compare Mambu's Communications log timestamps with your own application and infrastructure logs.
  • Evaluate endpoint responsiveness: If requests using the same network route succeed intermittently, we recommend reviewing your infrastructure logs to identify any transient endpoint responsiveness or local network issues.

When to contact Support​

If you have verified your endpoint performance and logs but still cannot identify the cause of persistent delays:

  1. Collect the following evidence:
    • Channel (Email, SMS, Webhook).
    • Notification IDs from the Communications log.
    • Timestamps of the affected notifications.
    • Relevant logs or metrics from your side showing endpoint responsiveness.
  2. Open a case with Mambu Support and provide the gathered details to help the team correlate your findings with system telemetry.

See also:

Last updated on