Scheduled message send: write now, send later.

Sometimes the most important thing about a message isn't what it says — it's when it arrives. You want a message to go out at a precise future moment: when you'll be on a plane, across a border, in a meeting, asleep, or simply unavailable. Composing it now and trusting yourself to hit send at exactly the right instant is fragile and, in some situations, impossible. Scheduled send fixes that: write the message now, encrypt it, set a time, and let the app release it when that time arrives. It's a genuinely useful piece of timing control — and it has one honest limitation you must understand before you rely on it, because the difference between an in-app scheduler and a guaranteed background push is the difference between "usually works" and "fires no matter what." Here's exactly how it works and where that line falls.

1. What scheduled send actually is

Scheduled send lets you compose a message now and designate a future time for it to be sent, rather than sending it the moment you finish writing. You write it, encrypt it, pick a moment — an hour from now, tomorrow morning, next Tuesday at 9am — and hand it to the app to release at that time. Until then it sits queued, sealed and waiting. When the scheduled moment arrives, the app sends it as if you'd composed and sent it right then.

The value is decoupling composition from delivery. Normally those two acts are welded together: you write, you send, it goes. But the moment that's best for you to write a message is very often not the moment it should arrive. You may be available to compose now but deliberately unavailable later — in transit, in a meeting, offline by design. You may want a message to land at a specific time for reasons that have nothing to do with when you happened to be at your keyboard. Scheduled send breaks the weld, letting you control delivery timing independently of composition timing.

It's worth being precise that this is a convenience and timing-control feature, not a security primitive in the way encryption or a dead drop is. The message is still end-to-end encrypted — scheduling doesn't weaken that — but the scheduling itself is about when, not whether something can be read. For genuinely safety-critical automatic sending tied to your own unavailability, the right tool is a dead man's switch, which is engineered around exactly the failure modes a simple scheduler isn't. Keep that distinction in mind; we'll return to it in the limits.

2. How queuing a message for later works

The mechanism is simple, and understanding it is what makes the limitation obvious later.

Compose and seal now

You write the message and Helix encrypts it immediately, end-to-end, addressed to the recipient — exactly as it would for an instant send. The encryption happens at composition time, so the queued item is already sealed ciphertext, not plaintext waiting around to be encrypted later. Whatever rests in the queue is already protected.

Set the release time

You attach a target time to the queued, sealed message. The app records that the message should be released when that moment arrives and holds it in a pending state. Nothing is sent yet; the message simply waits its turn.

Release at the appointed time

When the scheduled time arrives, the app's scheduler triggers and sends the queued message through the normal encrypted delivery path — the same route any message takes. From the recipient's side it's an ordinary encrypted message that happened to arrive at the chosen moment. From your side, you did nothing at send time; the app acted on your earlier instruction.

The crucial detail: where the timer lives

Here is the detail that defines what scheduled send can and can't promise: the timer lives in the app, on your device. It is your device's app, waking up at the right time, that releases the message. This is what makes it private — nobody else holds your queued message or knows your schedule — and it's also precisely what bounds its reliability, as we'll cover honestly below. The scheduler is yours, which is good for privacy and is the reason it isn't an ironclad guarantee.

3. The problem it solves

Scheduled send isn't built to defeat an adversary so much as to solve a real operational problem: getting the right message to arrive at the right time when you can't or shouldn't be the one pressing send at that moment. That problem shows up constantly in the lives of people who operate under timing constraints.

You're about to fly and need a confirmation to land while you're in the air. You're crossing a border in travel mode with your device locked down and don't want to be actively messaging at the checkpoint, but a counterparty needs a note at a set time. You're going into a long meeting and want an update to go out partway through without touching your phone. You're in a different time zone from the recipient and want your message to land at a civilized hour for them, not a 3am ping that wakes them. In every case the issue is the same: composition and delivery need to happen at different times, and relying on yourself to manually send at the exact future instant is unreliable or simply not possible. Scheduled send removes the need to be present at delivery time. It pairs naturally with asynchronous tools like encrypted dead drops — both are about decoupling your availability from the act of communicating.

4. Who this is for

Anyone whose communications have to be timed precisely but who can't always be available at the precise moment of delivery.

• Crypto holders and whales. Coordinating a time-sensitive action — a notification to a counterparty, a check-in tied to a window — without having to be on your device at that exact, possibly exposed, moment. Compose in a safe moment; let it deliver in the right one.
• Lawyers. A message that should reach a client or co-counsel at a set time — a deadline reminder, a confirmation timed to a filing — composed when you have a free moment and released when it actually needs to land, without you interrupting court or a meeting to send it.
• Family offices and executives. Instructions or updates timed to a market open, a board moment or a counterpart's time zone, written in advance and delivered on schedule so the timing is right regardless of where you are when it goes.
• Journalists and their sources. A check-in or confirmation timed to a specific window — useful when you'll be in transit, in a meeting or deliberately offline at the moment it needs to arrive. Write it while you can; let it go when it should.
• The targeted. Anyone who needs a message to arrive at a controlled time while they're unavailable, in transit, or keeping a low profile — without depending on themselves to manually fire it off at a moment when doing so might be inconvenient or unsafe.

5. How Helix implements it

Helix builds scheduled send as a private, on-device timing-control feature on the phone you already carry — standard iOS and Android — with a few deliberate choices.

• Encrypted at composition. The message is sealed end-to-end the moment you write it, so what waits in the queue is ciphertext, not exposed plaintext. Scheduling never weakens the encryption.
• The schedule stays on your device. Helix doesn't hand your queued message and your timing to a server to release on your behalf — that would mean a third party holding your sealed message and knowing your schedule. The scheduler is local, which keeps both the message and the timing private to you.
• Honest about what it is. Helix presents scheduled send as a convenient in-app scheduler for timing control, and steers you to the dead man's switch for anything safety-critical that must fire even if your device is off, dead or seized. Different jobs, different tools — stated plainly.
• It's one layer in a posture. Scheduled send sits alongside dead drops, the dead man's switch and the rest of the Helix feature set. It's the right tool for "deliver this at a set time while I'm unavailable," not a substitute for the tools built around guaranteed execution.

6. The honest limits — read this part

We'd rather you understand this clearly than be surprised by it later. Scheduled send is reliable for ordinary use and is not an ironclad guarantee.

Unpack why, because it follows directly from the on-device design.

The OS controls whether your app runs

On modern phones, apps do not get to run whenever they like. To preserve battery and performance, iOS and Android aggressively suspend, throttle and outright terminate background apps, and they grant only limited, best-effort background execution. This is generally good for your device — but it means an app's scheduled timer is at the mercy of the operating system's willingness to wake it. If the OS has the app suspended at the scheduled instant, the send may be deferred until the next time the app is allowed to run, which could be moments later or considerably later depending on the platform's mood, your battery state and your settings. The scheduler aims at the appointed time; the OS decides whether it gets to hit it precisely.

Device state matters

Because the timer lives on your device, delivery also depends on basic device conditions at the scheduled moment: the device needs to be powered on, and it needs network connectivity to actually transmit. If your phone is off, out of battery, or has no signal when the timer fires, the message can't go out at that instant — it'll be sent when conditions allow, not necessarily on the dot. A scheduled send is a best-effort instruction to your own device, and your own device has to be in a state to carry it out.

When you need a guarantee, use the right tool

This is exactly why Helix does not pretend scheduled send is a guaranteed delivery mechanism, and why we point you to the dead man's switch for safety-critical automatic sending. A dead man's switch is engineered around the assumption that your device might be off, dead or in someone else's hands — it's built to fire under exactly the conditions where an in-app scheduler can't. Conflating the two is a dangerous mistake: scheduled send is convenience and timing control, not a fail-safe. If a message absolutely must go out regardless of your device's state, scheduled send is the wrong tool and we'll tell you so.

So why is scheduled send worth having? Because for its actual job — delivering an encrypted message at a chosen time when your device is on, connected and able to run the app, which is the overwhelmingly common case — it works well and removes the need for you to be present at the send moment. The limitation is real and bounded: it's a timing-precision and best-effort-delivery constraint on a stock phone, not a flaw in the encryption, which holds the entire time. Use it for ordinary timing control, reach for the dead man's switch when a send must happen no matter what, and you're matching the tool to the job instead of trusting a convenience feature with a life-or-death task. That honest matching is the definition of winning here.

7. The bottom line

Scheduled message send breaks the weld between writing a message and delivering it: compose and encrypt now, set a time, and let Helix release it when that moment arrives — without you having to be present to press send. It's genuinely useful for the constant real-world problem of needing a message to land at a precise time when you'll be in transit, in a meeting or otherwise unavailable. The honest limit is that it's an in-app scheduler running on your device, not a guaranteed background push: delivery depends on your phone being on, connected and allowed by the OS to run the app at that instant, and aggressive background management can delay a precisely-timed send. For anything where a missed send is unacceptable, the dead man's switch is the tool built for it. Use scheduled send for what it's good at, and don't ask a convenience feature to carry a guarantee it was never designed to make.

$199/month Core · $499/month Operator · $999/month Sovereign — or 30% off paid annually. Buy it or don't — no negotiation, no surprises.