Scheduling an issue

Scheduling sends an issue at a date and time you pick, in your newsletter’s timezone. Issue Mint checks every minute for issues whose time has arrived and starts them, so nothing depends on you being at a desk.

Everything sending now checks is checked here too, both when you schedule and again at the send time.

Times are the newsletter’s, not your browser’s

The schedule field speaks your newsletter’s timezone, and the zone is named underneath it so there is nothing to infer.

It opens on tomorrow at your newsletter’s usual send time, because by the time most people are writing, today’s send time has gone. Your newsletter’s schedule is where that time and that zone are set. Once scheduled, the panel reads the time back in the same zone and names it, so managing a New York newsletter from London shows you the New York time you chose rather than a conversion you then have to undo in your head.

What scheduling checks

A time in the past is refused, judged in your newsletter’s timezone rather than ours, so an afternoon slot west of Greenwich is accepted as the future it is.

Every publish blocker is checked at the moment you schedule, and reported against the field: no subject, no links, a trial that has ended, a sending account that needs attention, or a list larger than a hosted sending limit allows. Scheduling is not a way round any of them, because the same checks run again when the time comes.

Unscheduling, up until the send starts

Back to draft takes the issue off the schedule and clears the time. It works while the issue is still scheduled, and not after that.

Once a send has started there is nothing to unschedule, and Issue Mint refuses rather than pretending. The minute-by-minute dispatcher only ever claims issues that are still scheduled when it reaches them, so if you press Back to draft while it is working through a batch of due issues, your press wins and the issue stays a draft.

If something changes before the send time

A blocker that appears between scheduling and the send time parks the issue back to draft with the reason written on it, rather than sending anyway or retrying every minute for ever.

The two common causes are a trial ending in between and, on your own sending account, credentials that stopped working. The reason appears at the top of the composer and against the issue in the issues list, which matters because a parked issue is a draft among other drafts and the list is where somebody notices that this week’s issue did not go out.

A scheduled date picks up a confirmed sponsor

Scheduling an issue for a date that already has confirmed bookings from your sponsorship calendar attaches them to that issue, and the confirmation says how many. The dates are matched in your newsletter’s timezone, because the date you sold a sponsor is a calendar date rather than an instant, and comparing it against a stored time in another zone is how a paid placement quietly goes missing.

Attaching records which issue a booking belongs to. It does not write the sponsor into your issue: the Sponsors panel then offers each one, and inserting is a button you press, described on sponsored items. A booking confirmed later, for a date that already has a draft or scheduled issue, is attached from the other direction, so the order the two things happen in does not matter.

A scheduled first send is reviewed on the same rules

A first ever send above the review threshold is held whether you press send or schedule it, because the check sits in the publishing path rather than on the button.

An issue scheduled for three in the morning is exactly how somebody would route around a queue that only existed on the Send button, so it does not exist only there. When it happens, the issue moves to waiting for review at its scheduled time and you are emailed, and a held first send covers what follows. It is not treated as a failure and the issue is not parked back to draft.