Automations that actually run

The best automations are the ones you can forget about: a Monday digest waiting when you start work, meeting notes arriving without a manual export, a health check catching trouble before you feel it. The important word is can. A scheduled job existing is not proof that it ran, and a quiet computer is not always a healthy one.

This page shows you how to set an automation up in one sentence, how to tell whether it is genuinely working, and how to use session start as a safety net when a missed run would matter.

Setting one up is a sentence, not a project

Computers have had schedulers for decades. A Mac normally uses launchd; Windows uses Task Scheduler. You do not need to learn either one. Describe the outcome and schedule in chat and ask Dex to do the wiring:

I want [JOB — e.g. "a Monday-morning digest of the week ahead"] to run
automatically at [TIME/FREQUENCY] on this computer. Set up the scheduled
job for me — explain what you're creating and where it lives, create it,
then prove it works by running it once now. Also tell me how to see its
last result, pause it, and remove it later.

Dex ships optional Mac background jobs for meeting sync, its nightly self-test, and learning reviews. On Windows, Dex can help you create the equivalent Task Scheduler job, but those bundled Mac installers do not silently create a Windows task for you.

The quiet failure to design for

What happens while your computer is asleep depends on the scheduler and how the job was configured. Some missed jobs run after wake. Some are skipped. Some report a failure in a log nobody ever opens.

So the safe rule is simple: do not treat a schedule as proof of execution. Give every important job a small last-run record containing when it started, whether it finished, and whether it succeeded. Then you have evidence instead of hope.

For a low-stakes job, a visible log may be enough. For anything that feeds your week — meeting notes, a customer digest, a backup — add a second mechanism that checks the record.

Session start is a useful safety net

Dex can run small steps automatically at fixed moments. These are called hooks, and our Claude Code page introduces them properly. The useful moment here is session start: every time you open a Dex conversation, the hook gets a chance to ask whether anything important is stale.

The trustworthy pattern is:

1. The scheduled job records its result.
2. Session start compares that result with the intended schedule.
3. On time → silence.
4. Stale → warn you, or run a catch-up only if the job was deliberately designed to be safe to repeat.

That last distinction matters. Automatically rerunning an idempotent read-only digest is usually safe. Automatically retrying a job that sends messages or changes external data may duplicate work. Ask Dex to design the catch-up behavior explicitly rather than treating every missed job the same.

What Dex does today

Released Dex already uses several parts of this pattern:

• Learning reviews have a throttled session-start fallback, so the check can still happen even when the optional Mac background job is not installed.
• The nightly health check can run at the first session of the local day if the overnight job did not leave a clean result.
• Meeting processing is checked at session start. Dex reports notes that are waiting, but it does not silently process them; run /process-meetings when you want person pages, tasks, and filing updated.
• Background-job freshness is checked from the job logs. If meeting sync, the nightly smoke test, the update watcher, or learning review is stale, Dex tells you to run /dex-doctor.

That is a safety net, not one magical universal sweeper: each job has the recovery behavior appropriate to what it can change.

Put the net under your own jobs

Once you have scheduled jobs of your own, ask Dex to audit them before adding catch-up behavior:

Inventory every scheduled job we've set up on this computer. For each
one, show me its schedule, its last recorded result, what happens after
a missed run, and whether repeating it could duplicate messages or
external changes. Add a session-start warning for anything important
that can silently go stale. Propose automatic catch-up only for jobs
you can prove are safe to repeat, then test one missed-run scenario.

Make it your own: the sharp question is not “is this scheduled?” It is “what evidence proves it ran, and what safely happens when it did not?”

First, fetch and read the page I'm referring to: https://heydex.ai/help/automations.md

I just read the Dex Guide's page on automations. Audit this machine:
every scheduled Dex job and every job we've added, when each last ran,
whether it succeeded, and what happens after a missed run. Rank the
silent failures by how much they would cost me. Fix safe reporting and
session-start warnings yourself; show me before adding any automatic
catch-up that could send, publish, delete, or change external data.