What’s the difference between real-time and delayed triggers?

Real-time and delayed triggers are both event-based automations. The difference is how long the system waits after the event before sending.

Real-time triggers fire in seconds

A real-time trigger means the email leaves your ESP within seconds of the event. The user does something. The send goes out. No waiting room.

Classic examples:

• Order confirmation. Customer hits "Place order." Receipt arrives before they close the tab.
• Password reset. User clicks "Forgot password." Token email lands inside 10 seconds or they assume it broke.
• Login alert from a new device. Security depends on speed. If the alert arrives an hour later, the account is already drained.
• Two-factor codes. Codes typically expire in 5 to 10 minutes, so the email has to land in seconds.
• Magic link sign-in. Same idea. The user is sitting on the login screen waiting.

These are transactional sends. The user just did something and is actively waiting for the email. Any delay feels broken. Mailbox providers know this pattern, which is why transactional streams from a dedicated IP usually have the highest inbox rates in your account.

For real-time triggers you want a separate sending stream (a different subdomain or IP pool) so a marketing send going slow does not delay a password reset. Postmark, SendGrid, Brevo, AWS SES, Mailgun and Resend all let you split streams. Use it.

Delayed triggers wait on purpose

A delayed trigger fires the event into a queue, then waits a set time before sending. The wait is the whole point. You are giving the user a window to finish what they started, or you are spacing messages so the inbox does not get hammered.

Common delays:

• Abandoned cart: wait 1 to 4 hours. Klaviyo's benchmarks show the first cart email sent 3 to 4 hours after abandonment tends to outperform same-minute sends, because some shoppers were just comparing tabs.
• Browse abandonment: wait 30 minutes to 2 hours. Same logic as cart but weaker intent signal, so the delay is shorter and the message softer.
• Welcome series: email 1 sends right away. Email 2 waits 1 to 2 days. Email 3 waits 3 to 5 days. The spacing keeps you from looking desperate.
• Post-purchase review request: wait until the product has plausibly arrived. For a physical product, that is 7 to 14 days, not 1 hour.
• Trial expiry nudge: wait until day 11 of a 14 day trial. Sending on day 1 is pointless.
• Winback: wait 60 to 90 days of inactivity before the first re-engagement attempt.

Delay also exists for a second reason that is easy to miss: cancellation. While the email is sitting in the queue, the system is watching for a counter-event. Cart abandoner came back and bought? Cancel the email. User reset their password before the "did you forget?" reminder fired? Cancel it. Without that cancellation logic, you send irrelevant emails and train people to ignore you.

How to pick which one

Three questions decide it:

1. Is the user actively waiting? Yes means real-time. A password reset, a 2FA code, an order receipt, a download link. If the user is sitting on a screen expecting an email, do not delay.
2. Could the event reverse itself? Yes means delay. A cart can be completed. A trial can be cancelled and restarted. A user marked inactive can log back in. Give the reversal a window.
3. Will more emails be helpful or annoying? Welcome and onboarding series fire one event (signup) but space messages across days so each one is useful. That is delay used as pacing, not as confirmation.

The RFC 5321 spec for SMTP allows servers to defer mail, so even a "real-time" trigger is at the mercy of the receiving server. See RFC 5321 section 4.5.4.1 on retry timing. Practically this means: if your password reset arrives 90 seconds late once in a while, the delay is probably at Gmail or Yahoo, not your ESP. Build your UI to say "check spam, may take a minute" instead of promising 5 seconds.

One last thing. Delayed triggers can pile up if you change the wait time mid-flow. If a cart flow has 50,000 users sitting in a 4 hour queue and you drop the wait to 30 minutes, 50,000 emails fire at once. Google calls this kind of traffic spike out in their sender guidelines as a reason for sudden filtering. Change wait times during low-traffic hours, or stage the cutover.

Real-time says "the user is waiting right now." Delayed says "let's see if anything changes first." Most automation programs need both, on separate streams, with cancellation logic on the delayed side.