If you write one letter to your future self in your life, and it doesn't arrive, you'll never know. That's the specific horror of a time capsule failure: the person who was going to be moved by it is exactly the person who won't find out it went missing.
Storing a letter for ten years is easy. Databases do that. The hard problem — the one every service in this category quietly struggles with — is delivering to a person whose contact details have changed while the letter was waiting.
Here's what actually has to work.
The problem, in one paragraph
The average American changes email providers about every six years. They keep the old one, sometimes, but stop checking it. If you sealed a letter today addressed to your primary inbox, and set it to arrive in a decade, there's a real chance — call it a coin flip — that on the day of delivery, that inbox will either be a spam farm or a disabled account. The letter will bounce. If the service tries five times and gives up, which is the industry norm, your letter is gone.
What "arriving" actually requires
Four things, in order of who's responsible for them.
One: You have to have given the service a way to find you that will still work later. Most services only accept one address. If yours does, it stops being your fault the moment you fill it in — you've done your part. But it's still your letter that's at risk.
Two: The service has to be alive on delivery day. This is not guaranteed. Most digital services from a decade ago no longer exist. The service you pick has to have a plan for its own end that doesn't take your letter with it.
Three: The delivery infrastructure has to try hard enough. Not five retries. Not a week. If the primary address bounces, there has to be a real fallback chain that includes at least one channel you're likely to still use.
Four: If everything fails, the letter has to survive as something you can still claim later. A letter that a service "tried to deliver" and then deleted might as well have never existed.
What we actually do
I'll walk through each of the four requirements above and describe what this service does about it.
Two addresses, on different providers
When you seal a letter here, we ask for a primary email and a backup. The backup is optional but heavily suggested — anything over one year, we make the case for it before you seal.
The reason it has to be a different provider is subtle. If both addresses are, say, Gmail, and Gmail has a bad day (or your Google account gets suspended for a Terms of Service issue you don't notice), both of your delivery paths go down at once. Two different providers means the probability that both are dead on the same day is much lower.
A dead man's switch
This is the single most important thing this service does and also the least visible one.
There is a scheduled task, running independently of the main application, that checks in every day. Its only job is to notice if the service is being wound down — either because I decide to stop running it, or because I've stopped responding for six months. If either of those triggers, the task starts delivering every unopened letter early, ahead of schedule, with a short explanation attached.
This mechanism means the failure mode of "the service disappears and your letter with it" is not on the list of things that can happen. Your letter arrives on its scheduled date, or it arrives early because we're shutting down, but it arrives.
This is written into our terms of service, not just this blog post.
A real retry chain
The delivery flow on the scheduled date is not "send email, wait, give up." It's:
- Try the primary address. If it delivers, done.
- If it bounces or fails, try the backup address.
- If both fail, mark the letter as unclaimed and start a slow retry schedule — monthly for the first year, quarterly for at least three years.
- In parallel, put the letter into a claim queue tied to your original account, so that if you ever log back in, you'll see it waiting.
The claim queue is important. Even after three years of retries, if the letter genuinely can't be delivered by email, it stays available for you to open manually. It does not get deleted.
Retention after delivery
A letter that arrives and then disappears is a different kind of failure but the same underlying disrespect. If you open a ten-year letter, you're going to want to reread it a week later, a year later, at your kid's graduation. We keep everything you write here until you delete it. Not thirty days. Not five years. Until you say so.
What still doesn't guarantee anything
I want to be careful here. No amount of engineering makes a ten-year letter certain to arrive. If you die before the delivery date, the letter goes to your inbox and no one you'd have wanted to read it will. If the entire internet goes down permanently, we're all in bigger trouble than the letter. If someone with access to your accounts deletes them, we can't undo that.
What engineering can do is remove the failure modes that are actually likely — dead inboxes, bankrupt companies, retry logic that gives up too soon. Those are the ones that have taken down almost every failed letter for the last twenty years. That's what this service is built to remove.
The best version of this promise is not a marketing claim. It's a scheduled task, a fallback chain, and a set of terms of service you can read. All three exist. Read them if you want. Then seal your letter and forget about it for a decade.