Every "best time to send email" article on the internet is about marketing email. Transactional email obeys a completely different rule: send it the instant the event fires, always, no exceptions worth remembering.
Why marketing timing doesn't apply
Marketing emails are broadcasts to a list — the recipient didn't ask for one this second. Timing matters: 10am Tuesday gets more opens than 3am Sunday because inboxes are being checked.
Transactional emails are triggered by a user action. They ordered something, reset their password, submitted a form. The recipient is waiting for the email. Every second of delay reduces trust and increases support tickets.
The 30-second rule
A transactional email that takes more than 30 seconds to arrive triggers a mental "something's wrong." The user hits refresh. They open a support chat. They try the password reset again, generating a duplicate. Your queue lengthens; their frustration grows.
Aim for < 5 seconds from event to inbox for password resets, receipts, and order confirmations. Shipping updates and daily digests can be slower — but those aren't really transactional, they're scheduled.
The two exceptions
1. Rate-limit sensitive receivers
If you're about to send 100k password resets after a security incident, Gmail's per-domain rate limiter will drop mail on the floor. Batch these to 5,000/hour with a small buffer. The exception is only for burst events, not steady traffic.
2. Off-hours password resets to enterprise domains
A password reset request at 3am local time to a corporate domain may be suspicious. Some products delay to business hours + notify security. This is a security decision, not a deliverability one — and the delay should be a policy choice, not an infrastructure limit.
What breaks "send immediately"
The usual suspects: a queue that batches every 5 minutes, a background worker that only runs on cron, a webhook that retries with exponential backoff. Each looks reasonable but stacks up to 30+ seconds of delay.
Send transactional email inline from the request handler. Yes, it's slightly more latency in the response. Yes, it's worth it.
If you're still queuing transactional email, ask: what would break if I sent it inline? Usually the answer is nothing. Ship the change.