The right time to send a cold email is not a universal 10 AM Tuesday. It is a function of the recipient's time zone, their ISP's delivery behavior, their industry's work pattern, and their personal engagement history. NimbusOS send time optimization looks at all four and picks a window that maximizes open and reply probability without ever batching sends into a spammy-looking burst. This article walks the decision layers, the configuration options, and the fallback logic when data is thin.
The Four Decision Layers
Send time selection runs a cascading check. Each layer narrows the candidate window until a final send slot is chosen.
Layer 1: Recipient time zone
The first filter. A send meant to land at 10 AM local should not fire in your time zone; it should fire in the recipient's. NimbusOS resolves the recipient time zone in three ways, in priority order.
Explicit field. If the contact record has time_zone set, it is used. Custom imports often include this.
Location derived. If city, state, or country is set, a geocode lookup maps to a time zone. Location to time zone mapping handles multi-zone countries (United States, Canada, Russia, Australia).
Domain heuristic. For missing location fields, the company domain TLD hints at region. .de suggests Central European, .au suggests Australian Eastern, and so on. Heuristic time zones are marked low confidence and the platform widens the send window when it relies on them.
Fallback. If all three fail, the workspace default time zone is used. Log a warning on the contact so the gap shows up in data quality audits.
Layer 2: ISP delivery pattern
Different ISPs deliver differently. Gmail holds messages briefly for spam scoring and delivers within a few seconds. Microsoft 365 with Enterprise ATP can hold messages for 30 to 90 seconds while the message is scanned in the protected environment. Yahoo's delivery lag is longer still.
NimbusOS learns the pattern from the send outcome history. SendOutcomeLog rows track send time, delivery time, and open time per ISP. The average delivery lag feeds back into send time selection: for a Microsoft 365 recipient, a send fires 60 seconds earlier than for a Gmail recipient to hit the same inbox arrival time.
ISP specific windows also differ. Gmail B2B readers open most frequently between 9 AM and 11 AM and between 2 PM and 4 PM local. Microsoft 365 enterprise readers skew earlier, 8 AM to 10 AM. Yahoo consumer readers skew later, 11 AM to 1 PM. These patterns are stored in the platform's engagement analytics and refreshed weekly.
Layer 3: Industry send pattern
The third layer looks at industry patterns. A CFO in financial services has a different reading rhythm than a developer in SaaS. The platform aggregates SendOutcomeLog by industry (inferred from the company record) and computes open and reply rate heat maps by hour and day.
Two strong industry signals in the data.
Technology and SaaS. Replies concentrate heavily between 9 AM and 11 AM Tuesday through Thursday. Friday afternoon is the worst window in the week.
Financial services and legal. Replies spread more evenly. Early morning (7 AM to 9 AM) is strong, late afternoon (4 PM to 6 PM) is almost as strong. Tuesday is the peak day, Wednesday close behind.
If an industry does not have enough data in the workspace to be confident, the platform falls back to the cross-workspace Growth Brain aggregate, which has much larger sample sizes.
Layer 4: Per contact engagement history
The tightest layer. If a specific contact has engaged before, the platform looks at when they opened and replied. A contact who consistently opens at 7 AM local gets their next send at 7 AM local. A contact whose last three opens were on Monday morning gets their next send on Monday morning.
Engagement history requires at least two prior engagement events. Below that, the contact falls back to the industry pattern.
Configuration Surfaces
Send time optimization has two layers of configuration: campaign level and step level.
Campaign level
The campaign object holds three fields that shape the send window.
send_window_start and send_window_end. Hours of day in the recipient's local time. Default 9 to 17. Narrowing to 9 to 11 concentrates sends into the highest-probability window.
send_days. Bitmask of days of the week. Default is Monday through Friday. Weekend sending for B2B cold outreach has low open rates and high unsubscribe rates.
smart_time_gaps. Boolean, default true. Randomizes the interval between consecutive sends inside the window. When off, sends go out in a deterministic rhythm, which looks mechanical and hurts reputation.
Step level
Individual steps can override the campaign defaults.
send_time_mode. One of immediate, business_hours, specific_time, optimized. Default is optimized which uses the four layer decision. business_hours restricts to the campaign window without per contact optimization. specific_time sends at an exact hour you specify.
send_hour and send_minute. Used when send_time_mode is specific_time.
A common pattern is optimized on step 1 and business_hours on follow ups. The first send warrants the full optimization; follow ups can stay in the broader window without much accuracy loss.
The Hardcoded 10 AM Fallback (And Why You Should Override It)
Historical note. The send engine has a hardcoded fallback of 10 AM in America/New_York when no other data is available. This fallback is defensive: it prevents a send from firing at 3 AM if every other signal is missing.
But relying on the fallback for a large list means every send fires in the same 10 AM New York window, which is an obvious batching signal to ISPs. The optimize-send-schedule skill in the platform produces per-tier send schedule recommendations that override the fallback. For any campaign sending more than 100 emails per day, apply the recommendation rather than accepting the fallback.
Time Zones Inferred from the Email Domain
A useful corner case. When time_zone, city, state, and country are all blank, the platform extracts a signal from the email domain's MX record region. acme.com with an MX record in us-east-1 suggests the company operates primarily in the US Eastern time zone. This is a weak signal and flagged as such, but it is better than nothing for companies that do not publish location on their marketing site.
Send Windows Across Daylight Saving Transitions
The engine uses full IANA time zone data, not fixed offsets, so daylight saving transitions are handled correctly. A campaign configured for 9 AM America/Chicago sends at 14:00 UTC in January and 14:00 UTC in March after the spring-forward transition. No manual adjustment needed.
Rate Limiting and the Send Window
Send time optimization cooperates with the daily rate limits. If the campaign's max_new_leads_per_day is 50, the engine spreads 50 sends across the configured window. Spreading is smart-random by default: not evenly paced, which would look mechanical, but not bunched at the start or the end.
When the window is narrow and the daily cap is high, the engine warns at configuration time. A 9 AM to 11 AM window with a 200 per day cap sends roughly 100 per hour, which is a bunched pattern. Expand the window or reduce the cap.
Opting Out of Optimization
Some campaigns should not be optimized. Event follow ups, post webinar sends, and urgent responses all have a time value that overrides the engagement pattern.
Set send_time_mode=immediate on the step, or pick a specific time. The engine respects the override.
Measuring the Impact
The Send Time Optimization analytics page compares open and reply rates between optimized and non optimized sends in the same campaign. The difference is usually visible after the first 200 sends. Expect 3 to 7 percent absolute lift in open rate and 1 to 3 percent absolute lift in reply rate when the engine has enough per contact or per industry signal.
For new workspaces with thin data the lift is smaller. It grows as the engagement history accumulates.
Troubleshooting
"My sends are firing in the middle of the night"
Time zone resolution failed and the workspace default is not set correctly. Go to Account Settings and confirm the default. Also check a sample of contacts for time_zone and location fields; if they are blank, the domain heuristic or the workspace default took over.
"The engine picked a send time I do not agree with"
You can view the decision rationale on the send detail. It shows which layer produced the time and the confidence level. Disagree by setting send_time_mode=business_hours and letting the campaign window govern directly.
"Open rate did not improve after turning on optimization"
The engine needs history to learn from. For a brand new workspace the lift is near zero in the first campaign because the platform has no data on the recipient industry or individuals. Expect the lift to show up from campaign three onward.
Frequently Asked Questions
Does send time optimization work for follow ups?
Yes, and follow ups actually benefit more than cold opens. A follow up to a contact who opened the first email at 3 PM has a much higher probability of being opened if the follow up also fires near 3 PM.
Can the optimization window be a fixed time rather than a window?
No. A single fixed time guarantees a bunched send pattern across all contacts who match that time. Narrow windows like 9 AM to 11 AM are the minimum practical configuration.
What if I want to send across time zones simultaneously?
That is exactly what the engine does. The same campaign sending to 200 contacts across four time zones will fire each send in the recipient's local window, so the UTC timestamps of the sends are spread across the day.
Is the optimization engine affected by holidays?
Yes, partially. Major US and UK holidays are detected and the send day skips them for contacts in those regions. Regional holidays not in the default list require a manual campaign pause for accuracy.
Can I disable the engine globally for a workspace?
Yes, in Account Settings. This sets all campaigns' default send_time_mode to business_hours. Individual steps can still opt into optimization.
What to Read Next
After tuning send timing, the most useful next pages are Campaign Analytics for reading engagement trends, Deliverability Overview for how send timing feeds into reputation, and Reply Intelligence for the reply timing analytics the engine reads back into its model.