How-to guides
Scheduling routines
Choose when a saved workflow runs. OOMU sleeps between exact deadlines and records every result.
Once a workflow does what you want, a schedule makes it run without you. Open Chat → Workflows and choose the Schedules & Triggers section.
Adding a schedule
Pick the workflow, then pick a frequency:
| Frequency | What you set |
|---|---|
| Hourly | Nothing else. Runs every hour. |
| Daily | A time. |
| Weekly | A first date and a time. |
| Weekdays | A time. Runs Monday to Friday. |
Times are set by the hour, in quarter-hour steps, with AM or PM. Advanced / Custom Cron adds two more:
| Frequency | What you set |
|---|---|
| Interval | A number of minutes. Between 1 minute and one year. |
| Cron | A five-field expression: minute, hour, day, month, weekday. |
Choose Add schedule. The panel confirms with "Routine added" and shows Next run {time}.
Every expression, however you entered it, is normalized and validated before it is stored. A cron expression that does not parse is refused rather than accepted and silently never fired.
Or create the workflow and its schedule together
Create scheduled workflow builds a web research workflow, its schedule, and an optional alert in one step: "Choose the action, timing, and optional alert. OOMU creates everything together."
Alert only when something changes
A schedule that looks something up every morning is only useful if it tells you when the answer matters. Turn on Alert only when something changes: "OOMU remembers the last verified value and stays quiet until your condition is met."
| You set | For example |
|---|---|
| Value to watch | "bunker fuel rate" |
| Alert when | Change is greater than a percentage, or Value falls below a number |
Each run reads the number from the sources it found, along with the page it came from and a quote showing it. The first run only records a starting value ("Waiting for the first verified value"). After that, you get a notification such as "{metric} changed by {change}% to {value}." when the condition is met, and nothing when it is not. The card shows the last value OOMU verified.
What happens when one fires
Each firing is a distinct occurrence, keyed to its exact scheduled time. That key is unique, which is what prevents the same slot running twice, including after a crash, a restart, or a clock change.
The occurrence claims a lease, runs the workflow, and records a run with:
| Field | Values |
|---|---|
| State | Completed · Waiting for information · Needs attention · Check required |
| Notification | Delivered · Failed · Not applicable |
| Times | When it was scheduled for, when it completed |
Recent runs shows the history under each schedule, marked Notified where a notification went out. A schedule that has not fired yet says so: "No runs yet."
How you hear about it
A completed scheduled run posts a macOS notification, such as "Deliverable ready: {workflow}". This needs Notifications access, which you can check in Settings → Connections & Apps → Mac access.
Failed and paused runs are recorded in the history and in Activity whether or not a notification was delivered: a failed notification never hides a failed run.
What a scheduled run can change
A scheduled run happens while you are not watching, so in Beta 4 it is held to the same rule as everything else OOMU does on its own: it can do the work, but it cannot approve its own work.
| A step that | In a scheduled run |
|---|---|
| Reads, searches, or looks something up | Runs as usual. |
| Writes a text file, a Word document, or an Excel workbook | Does not write to your folder. The file goes to Ready for review, with the folder it was meant for, and the run records that it is waiting for your approval. |
| Changes anything else: creates a note, a reminder, or an event, moves or trashes a file, runs a command, types or clicks on screen | Is refused before it runs, and the run records why. |
You approve a waiting file in Mochi's panel on your Mac, where you choose Documents, Desktop, or another folder. Or approve it from your phone with Slack or Discord, which saves it to the folder it was meant for.
This applies only to runs started by a schedule. When you run the same workflow yourself from Workflows, it behaves as it always has, with the usual approvals.
Missed runs
If your Mac was asleep or OOMU was closed when a schedule was due, the routine's missed-run policy decides what happens. Schedules you add in the app use Run once:
| Policy | Behavior |
|---|---|
| Skip | Missed slots are dropped. The next run is the next scheduled time. |
| Run once | One catch-up run, no matter how many slots were missed. |
| Run each | Catch up each missed slot, up to a cap. |
The cap is between 1 and 12 runs. Run once suits a daily digest: you get one fresh result, not a backlog.
Pausing and deleting
Every schedule has a toggle: Pause stops it firing while keeping it; Resume starts it again. Delete schedule removes it.
Routines can also pause themselves. If a required connection is missing or a controlled destination is no longer valid, the routine records a pause reason rather than running against a broken dependency.
Keeping work running after OOMU closes
Settings → General → Startup is where you decide whether scheduled work continues once the window is gone.
"Keep scheduled work running after OOMU closes. An installed OOMU app uses macOS Login Items."
Turn on Continue scheduled work and OOMU registers itself with SMAppService: the same mechanism behind Login Items in System Settings. The panel then reports:
| State | Meaning |
|---|---|
| Runs after OOMU closes | Registered and active. |
| Stops when OOMU closes | Not registered. |
| Needs Login Items in System Settings | macOS requires you to approve it there. |
| Available after OOMU is installed | OOMU is not running from a real application bundle. |
| Unavailable on this Mac | Not supported here. |
This is why installing to Applications matters. OOMU checks whether it is running from an application bundle before it will register. Running from Downloads or a build directory gives you Available after OOMU is installed and background work stays off.
The same panel shows Active routines, Next scheduled work, and Last activity, so you can confirm at a glance that something really is scheduled.
When OOMU restarts
On startup OOMU reconciles anything that was in flight:
- Expired routine leases are released, so a routine held by a process that is gone becomes claimable again.
- Workflow steps that were reserved are reset.
- Workflow steps that were mid-execution are quarantined as Check required, because OOMU cannot verify whether they finished.
All of that is logged. Nothing unverifiable is reported as either done or failed.
Related
- Building workflows: what a schedule actually runs.
- Working with Mochi: Ready for review, where scheduled files wait.
- Evidence & receipts: why "Check required" exists.