The best time to send cold emails (and why it matters less than you think)

The honest answer is that nobody has published a credible universal one, and the size of the effect you are chasing is smaller than the measurement error in the tool you would use to find it. Send in the recipient's local business hours, avoid the small hours, and stop there. Timing is a fourth-order lever behind targeting, the offer, deliverability and copy — and because Apple, Microsoft and every email security gateway now fetch your tracking pixel on delivery rather than on reading, the data you would use to optimise it is measuring machines.

What a send time can and cannot change

Separate two things that get collapsed into one word. Delivery is when the receiving server accepts your message and files it. Reading is when a person opens it. Your send time controls the first with reasonable precision and the second barely at all.

A message that arrives at 07:00 does not get read at 07:00. It sits in a folder until the recipient looks, and when they look is a property of their job, not your scheduler. A field engineer checks mail twice a day. A founder checks it at traffic lights. A procurement manager works a queue on Thursdays. There is no hour that is simultaneously correct for all of them, and the aggregate "best hour" you compute across a mixed list is an average of populations that do not overlap.

What the send time genuinely controls is position in the stack. A message that arrives while somebody is actively triaging sits near the top of what they see; one that arrives at 02:00 is buried under everything that landed after it. That is a real effect and it is why the advice to send during local business hours is sound. It is also a small effect, and it is the entire mechanism. Anything claiming more than that is claiming a psychology it has not measured.

The one randomised experiment that tested this properly

Most send-time advice traces back to a vendor blog that aggregated its own customers' sends and reported which hour had the highest average open rate. That design cannot distinguish a timing effect from the fact that different kinds of senders send at different hours. Newsletters go out in the morning; automated receipts go out all day; a careful sender who schedules for 10am is probably careful about their list too.

There is a properly randomised alternative, and it points the other way. Peter Lynn, Annamaria Bianchi and Alessandra Gaia ran a large-scale experiment on the Understanding Society Innovation Panel, published as "The impact of day of mailing on web survey response rate and response speed" in *Social Science Computer Review*, in which sample members were randomly assigned to receive an invitation on a Monday or on a Friday. The reported result is that they found no effect of day of invitation on participation, and none on prompt participation either — defined as responding within two days.

Two honest caveats before anyone over-reads that. It tested survey invitations to an existing panel, not cold commercial email to strangers, and it compared two days rather than hours within a day. But it is a randomised experiment with a control, which is more than any of the figures it contradicts can say, and its direction is consistent: when you remove the confounds, the timing effect gets small enough to disappear into the noise.

There is a serious modelling literature that finds send time does matter for opens — Singh, Sinha, Sinha, Garg and Banerjee's "An RNN-Survival Model to Decide Email Send Times", posted to arXiv in April 2020, builds a per-recipient model on exactly that premise. Note what it takes to extract the effect: a per-recipient survival model trained on a firm's own historical opens. That is the honest position. The effect is real, individual, and small enough that finding it requires machinery most teams do not have and data most cold lists do not contain.

Why your open timestamps no longer say when anyone read anything

This is the part that quietly invalidates most send-time work, and it is worth being precise about.

Apple's Mail Privacy Protection, which Apple describes on its own privacy pages, hides the recipient's IP address from senders and downloads remote content in the background when a message is received "rather than only downloading remote content when you open an email" — and it does that "regardless of whether you engage with the email". So for every Apple Mail user with the feature on, your tracking pixel fires shortly after delivery, at a time determined by Apple's infrastructure, and records an open that did not happen.

Microsoft is a second source of the same problem in a different shape. Outlook, Office and BingPreview fetch remote images on delivery as part of preview generation. So does every email security gateway in the enterprise stack — Proofpoint, Mimecast, Barracuda, Cisco IronPort, Forcepoint, Sophos, Fortinet, Trend Micro, Symantec and Cloudmark all follow links and fetch content to scan it. Those fetches carry identifiable user agents and can be filtered out. Apple's cannot be filtered from the user agent alone, which is why the honest treatment is to classify a pixel fetch that arrives with no user agent at all as machine traffic.

The consequence for send-time optimisation is direct. If you build an hour histogram from open events, a meaningful fraction of the mass in that histogram is the hour your message was *delivered*, not the hour it was read — and that hour is the one you chose. The histogram partly measures your own scheduler. Optimise against it and you converge on your existing behaviour while believing you discovered something. If you want the full picture of what an open event now contains, what email open tracking actually records walks the mechanism, and the open-rate benchmark problem covers why the published figures moved.

The arithmetic of how much a timing lift is worth

Work an illustrative example rather than trusting an intuition. These are made-up inputs chosen to be arithmetically clean, not measured figures.

Take a list of 1,000 leads and assume a 5% reply rate, giving 50 replies. Suppose a perfect send time lifts reply rate by a relative 10%, which is generous given everything above. That is 5.5%, or 55 replies — five extra conversations from a change you spent a week on.

Now compare the levers you skipped. Cutting the list from 1,000 loosely-matched leads to 400 tightly-matched ones and doubling the reply rate on those gives 40 replies from 400 sends, at a fraction of the sending volume and the reputation cost. Fixing a domain whose messages were landing in spam at all moves the number by more than either. The ordering is not close, and it is the same ordering every time: who you are writing to, what you are offering, whether the message arrives at all, what it says, and then the clock.

There is one asymmetry worth keeping. The downside of a bad send time is bounded and real — a sales email arriving at 03:00 in the recipient's country reads as automated before a word is read, and on the phone channels it is a regulatory problem rather than an aesthetic one. So the correct posture is defensive. Do not chase the best hour; eliminate the indefensible ones.

Autocloz's free plan covers 5 users and 10 mailboxes with per-lead sending windows and the quiet-hours gate on every channel — start free and set the window before you import a list, not after the first 03:00 send.

How to run a send-time test that can resolve

If you still want to test it, run a test that can produce an answer. Most cannot.

Step 1 — pick reply rate as the metric, not open rate. After the previous section, an open-rate test is a test of when mail servers fetch pixels. Reply is a human action with no machine analogue.

Step 2 — do the sample-size arithmetic first. You are comparing two proportions. If your baseline reply rate is 3% and the smallest difference worth acting on is one percentage point, you need thousands of sends per arm to distinguish 3% from 4% with any confidence. Write the number down before you start. If your list cannot supply it, the honest conclusion is that you cannot run this test, and the correct action is to set a sane window and spend the week on the list instead.

Step 3 — randomise at the lead, not at the day. Sending arm A on Tuesday and arm B on Thursday confounds the send time with everything else that differed between those two days, including which leads happened to be at the top of your queue. Split the same list randomly and send both arms in the same week.

Step 4 — hold everything else fixed. Same subject, same body, same mailbox pool, same step. If you change the copy at the same time, you have measured the interaction of two variables with one number.

Step 5 — decide the stopping rule before you look. "Run until 2,000 per arm, then read it once" is a rule. "Check daily and stop when one is ahead" is how you manufacture a winner out of noise.

Step 6 — re-run it in a quarter. A per-recipient timing effect is a property of your current list. Change the segment and the answer changes with it.

What Autocloz actually does with the clock

Three separate gates, and confusing them is the most common source of "my campaign is not sending" tickets.

The campaign sending window is a per-campaign workday-and-hours window. It is evaluated against the lead's own timezone field when the lead has one, falling back to the workspace timezone when it does not — so a list with populated timezones gets genuine per-recipient scheduling and a list without one gets your office hours. When it blocks a send, the enrollment is deferred with the reason Outside sending window and the wake-up time is computed by probing the same predicate that blocked it, so the row wakes when the window actually opens rather than on a flat retry.

Quiet hours are a separate, per-channel window set in Settings, Channels, with an optional per-campaign override. Email quiet hours resolve their timezone from the campaign override first, then the workspace, then UTC. For the phone channels the quiet-hours window is evaluated in the *sending account's* timezone, which is the right rule for a dialler with agents in one country and the wrong assumption if you expected it to follow the lead.

Send-time optimisation is opt-in, off by default, and set per campaign as optimize_send_time. When it is on, the worker reads up to the lead's last 50 recorded open events, converts each to the lead's local hour, and holds the send until the next of those hours using a plain histogram rather than a model. If the lead has no open history it sends immediately. The related recommendation endpoint scores hours as opens + 0.4 × clicks + 1.5 × replies — replies weighted heaviest deliberately, because reply is the metric a machine cannot fake — and refuses to trust a per-lead histogram built on fewer than three events, rolling up to the workspace histogram instead and finally to a static 14:00 UTC default.

That default is worth naming for what it is: a neutral midpoint that lands in the morning across most US and European zones when there is no data at all. It is a placeholder, not a finding. If you want to sanity-check a window against your own volume before configuring it, the send-time calculator does the timezone arithmetic, and the email autopilot surface is where the sending window and the per-channel caps live together.

Diagnosing a campaign that is stuck on a clock

Four failure modes, each with a distinct symptom.

• Everything defers with "Outside sending window". The campaign window and your leads' timezones disagree. Check whether the leads actually carry a timezone; a list imported without one inherits the workspace zone, so a US window on an India-timezone workspace can block all day.
• Sends fire, but at hours you did not configure. Two windows are both in play. The campaign sending window and the channel quiet hours are separate gates and both must pass; a send lands only in the intersection.
• Nothing sends and the reason mentions the workspace timezone. The workspace timezone is not a resolvable IANA zone, so the business-hours gate cannot evaluate and fails closed. This is deliberate — a window that cannot be evaluated must not become "send anytime".
• Send-time optimisation appears to do nothing. It is off unless the campaign sets it, and even then it only holds a send when the lead has open history and the preferred hour is still ahead. On a cold first touch, both conditions usually fail, which is the correct behaviour rather than a bug.

At one person, the clock is a setting you configure once. At ten, it becomes a coordination problem: reps in different countries, a shared mailbox pool, and campaigns inheriting a workspace window somebody set two quarters ago. The thing that scales is making the window a property of the campaign and the timezone a property of the lead record, then enforcing list hygiene so that field is actually populated. Cleaning and segmenting a list is the unglamorous work that makes per-recipient scheduling mean anything at all, and if you are weighing a scheduler against a dedicated sending tool, the Autocloz and Instantly comparison sets out where the two architectures differ.

What send-time optimisation does not do

It does not raise a reply rate that is limited by the list. If your leads are wrong for the offer, every hour is the wrong hour.

It does not survive a deliverability problem. A message that lands in spam at 10:00 lands in spam at 14:00. Authentication, list hygiene and volume ramp are the floor beneath all of this, and how many cold emails a day you can safely send is the constraint that actually caps your output.

It does not know when someone reads mail. It knows when a pixel was fetched, which is a different event, and after Apple Mail Privacy Protection those two things diverge for a large and unmeasurable share of any B2B list.

It is not a model. The shipped implementation is a histogram of a lead's own recorded open hours with a three-event minimum. That is a deliberate choice — a histogram captures most of the available signal at none of the operational cost of a model you would then have to retrain and explain — but it means the feature cannot discover a pattern that is not already visible in the lead's own history.

And it cannot fix a list with no timezones. Per-recipient scheduling degrades to workspace scheduling silently, without an error, because the fallback is the safe behaviour. If you want to know whether your sending window is doing anything at all, check what fraction of your leads carry a timezone before you check anything else.