When you send an email through Taguchi, you expect it to be delivered promptly. In most cases, this is exactly what happens. However, occasional delays may occur, and recipients may receive your message later than expected.

What might have happened?

Trigger Delays

Triggered email delays may occur when system processes take longer than expected to complete. This can happen due to high platform activity, background processing queues, or temporary system load.

Possible reasons

• Multiple activities being triggered at the same time can lead to queuing or delays in processing.
• Required fields within the activity may be missing or invalid, causing the system to skip or fail the trigger.
• An invalid or overly strict target expression can result in no matching subscribers.

For more information about Trigger Delays, please click here.

Broadcast Delay

Broadcast email delays can occur due to factors beyond the sender’s control. Recipient mail servers may take additional time to process messages, especially during periods of high traffic. Emails are also subject to spam and security checks, which can temporarily slow delivery.

Possible reasons

• High Sending Volume – Large email campaigns are often sent in batches to avoid overwhelming servers, which can slow down delivery.
• Spam & Security Filtering – Emails may be temporarily delayed as they are scanned for spam, malware, or suspicious content by recipient servers.
• Network or Server Congestion – Heavy traffic or temporary server issues on either the sending or receiving side can cause messages to be queued before delivery.

I scheduled my broadcast in Taguchi but still not delivering my Activity.

Delivery may be delayed during deployment for a number of reasons.

• Activity Size and target complexity - Activities with complex targets and big size might encounter delays from sending. Before the activity was sent, Taguchi needs to evaluate Target Expression conditions, filter millions of profiles, and prepare the final recipient list. With large behaviour-based targets like this, queuing can take 5–6 hours, while the actual broadcasting generally processes millions of sends per hour.

• Multiple activities sent at the same time - other activities that are scheduled to go out at the same time within the same instance may also compete for system resources and interfere with queuing, potentially causing further delays.

• System Issue - System failure will require to pause all sending including scheduled and event-based triggers during this time. Activities would have continued to queue and when activity was resumed, the backlog would have sent.

How can I manage Activities with large audiences?

When using very large audiences, it’s important to account for the queuing time in advance. For example, if the goal is for customers to see the email by 9:00 AM, starting the deployment 5–6 hours earlier allows the system to queue the recipients in time.

To help manage large audiences more efficiently, you may consider using Send Time Automation. feature. This feature separates queuing and deploying, allowing the system to prepare emails in advance before they are actually sent.

• Queuing Locks in recipients and personalizes content.
• Deploying When emails actually leave the system.

For more information about Broadcast Delays, please click here.

---