Use case

Catch delayed, cron & scheduled email

Most of the email your product sends is not instant. The trial-expiry reminder, the weekly digest, the drip step, the background-job notification — these fire long after you have finished a test session. The email that arrives next Tuesday is the one you can never seem to verify, because by the time it lands the inbox you tested with is gone. Perenmail keeps that inbox alive so the late send is simply waiting for you.

The problem with expiring inboxes

Testing an OTP or a password reset is easy: you trigger it, it arrives in seconds, you read it, you move on. Scheduled email breaks that loop. The send you actually want to inspect is decoupled in time from the action that caused it — sometimes by minutes, often by days.

An inbox that auto-deletes on a timer forces a bet you cannot win: you either sit and wait for a send that may be a week out, or you let the inbox lapse and lose the message entirely. When the day-11 trial reminder finally fires, there is nothing left to deliver it to. The scheduled job runs correctly, but you never get to verify it — so the one email most likely to ship broken is the one you never see.

Persistence removes the bet. When the inbox outlives the test session, the timing of the send stops mattering. You are no longer racing an expiry clock; you are just reading mail that was held for you.

How Perenmail handles it

Set it up once, come back whenever the send fires

  1. Step 01

    Create a persistent inbox and point your app at it

    Name a private address on a real domain and use it as the recipient for the flow you want to check — the trial signup, the digest opt-in, the drip enrollment. The inbox never expires on its own, so there is no countdown to beat.

  2. Step 02

    Close the tab and come back days later

    The email that arrives next Tuesday does not need you watching. Walk away, ship other work, and reopen the same inbox whenever the scheduled send is due. It is exactly where you left it, under the same project.

  3. Step 03

    The mail is already waiting

    Because the inbox persisted, the reminder or digest that landed while you were gone is sitting in it — headers, body and attachments intact. Nothing was auto-purged on a timer, so nothing is lost.

  4. Step 04

    Live delivery catches it the moment it lands

    If you happen to be looking when the scheduled job fires, a listening indicator and poll heartbeat surface the new message at the top instantly — no reload, unread updates in place. You see the delayed send arrive in real time.

  5. Step 05

    Search and markers pin it down

    Weeks of test mail add up. Group inboxes by project, label the runs with markers, and search across everything to jump straight to the day-14 reminder or the Monday digest you are verifying.

The kinds of sends this is for

Every one of these is email your own product emits on a delay. You point the flow at a private Perenmail address and inspect what actually arrives, whenever it arrives.

Trial-expiry reminder

The “your trial ends in 3 days” email your billing scheduler queues at signup — it fires on day 11, long after the QA session that created the account.

Cron digest

A weekly or nightly summary assembled by a scheduled job. You need to see the real Monday 9am send, not a hand-triggered dev preview.

Delayed receipt or invoice

Receipts that a background worker generates minutes or hours after checkout, once the payment settles and the PDF renders.

Drip-campaign step

Step 3 of an onboarding sequence that only sends 72 hours after enrollment. You want to confirm the copy, links and timing of that specific step.

Async webhook → email

A provider webhook that lands late and triggers a notification email. The whole point is to check what your app actually emits once the async event finally arrives.

Keep reading

Ready when you are

Stop missing the email that arrives next Tuesday.

Create a persistent inbox now and let the scheduled send land in its own time. Free forever, no credit card.