Skip to main content
A send made with --at stays manageable until it is due. mailkube scheduled-emails is where you look at those, move them, and call them off. scheduled is an alias for the group and reschedule for update. The shorter mailkube scheduled reschedule <id> means the same thing.
Scheduling is a plan feature. On a plan without it, a send with --at fails with scheduling_not_included and exits 5 rather than 3, because the credential was fine and the entitlement was not. See Scheduled emails for the horizon and the plan requirement.

​
Listing

Narrow it with any combination of a status, a batch and a time window:

​
Paging

A listing returns one page at a time. --page <n> reads a single page, and --all walks every page and hands back the items together. The two cannot be combined. --all means every page, so naming one as well is a contradiction, and it is refused rather than guessed at.
--all is for a filtered listing, not for a whole collection. Every page is a request, and requests are rate limited. Walking a large collection hits that limit long before it reaches the client-side ceiling of 1000 items. The run stops part-way with a rate-limit error instead of a complete answer. Filter first, then walk.
Nothing retries by itself. A rate-limited walk exits 7 and leaves the pacing to you. --max-items stops a walk after N items. It is client-side and is never sent to the server, so the pages it did not need are the pages it does not fetch: --max-items 5 across a thousand matches costs one request. It needs --all; there is nothing to stop otherwise. Reaching the 1000-item ceiling is reported on stderr, naming the count and the flag that raises it. It is never a silent truncation, because a listing that quietly stopped short would be indistinguishable from a collection that genuinely ends there, and that difference is the whole answer.

​
Rescheduling and canceling

update takes the same time formats as --at on a send, either RFC 3339 with an offset or a relative shorthand:
It can also move a send into a batch, keeping its time, with --batch-id.
Canceling asks for confirmation and defaults to no. Pass -y in a script. A send that is no longer pending, having already gone out or been canceled, fails with scheduled_email_not_pending.

​
Whole batches

--batch-id on the original send is what makes this possible. Once sends share a label, they move together:
Both act on every pending send in the batch. Sends that have already gone out are unaffected.

​
In a script

Output is JSON the moment it is not going to a terminal, so this needs no format flag:
See Scripting for --jq, the stream contract, and the exit codes worth branching on.