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 a session-start hook as a safety net when a missed run would matter. For the separate Proactive Health model that keeps the latest complete status visible, read Proactive Health.

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.

A session-start hook is a useful safety net

Claude Code hooks are small pieces of automation that run at defined points in its lifecycle. The SessionStart hook fires when a session begins or resumes. At session start, Dex reads local evidence — including the latest complete Proactive Health snapshot when one exists — without treating the hook starting as proof that the underlying checks finished.

It is not a scheduler, and it is not Claude improvising from memory. Your normal scheduler still does the work at the right time; the session-start hook is the check when Claude Code begins or resumes a session: did anything important get missed while I was away? For the fuller explanation of hooks, their guarantees, and the other moments they can run, see Session-start hooks in the Claude Code guide.

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 uses several parts of this pattern, with clear boundaries between them:

• Proactive Health reads the latest complete snapshot at session start. A failed or partial refresh cannot replace it; a newly critical result can interrupt, while warnings, staleness, and recoveries stay calm or unobtrusive. See the Proactive Health guide.
• Learning reviews and smoke checks keep their own local fallback and evidence. Those checks do not turn an incomplete health refresh into a complete status.
• 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.
• Doctor remains the place to inspect the underlying evidence and follow the repair path when an automation or dependency needs attention.

That is a safety net, not one magical universal sweeper: each job has the recovery behavior appropriate to what it can change, and Proactive Health does not repair anything by itself.

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.