The old paradigm is out. The new paradigm is AI. AI automation is InTouch AI. A schedule is the when of the contract you hand the engine: do this, on this calendar, alert these people, and when it breaks, don't just retry blindly — read the failure, know why, and fix what can be fixed. That contract sits in front of an AI core. The cron-string era couldn't read a failure if its life depended on it.
InTouch AI ships seven readable schedule types — Day, Week, Weekday, Weekend, Month/Specific Days, Month/Relative Days, Custom — with an intraday step control, an explicit daily cutoff, and a simulator that shows you the next N fire times before you flip the switch. Add timezones, blackout dates, expiration rules, and RBAC, and you have a scheduler that reads the same in six months as it did the day you wrote it.
Schedules are the deterministic edge of the determinism dial — the firing tick is identical every time, zero AI cost, fully audited. The intelligence lives in what happens when a run goes wrong, not in the calendar math. Here's what changes when scheduling stops being a syntax exercise.
Before: someone writes 0 9 1,15 * 1-5 at 11pm. Six months later, three people argue about whether it fires the 1st AND 15th, the 1st OR 15th of weekdays, or the 1st of the month plus weekdays.
After: pick a schedule type by its actual intent — "Month / Specific Days" with the days you want and the days-of-week filter. The setting reads the same in six months as the day you wrote it.
Before: schedules scattered across servers, kicked off by anonymous scripts, with permissions defined by file ownership. Auditors ask "who can change the close schedule" and you answer "anyone with sudo."
After: schedule objects with owners, groups, RBAC. The Department/Enterprise editions get per-object rights, blackout dates, and explicit expiration. Whoever changed it, when, why — in the audit log.
Before: deploy a schedule, wait until the next supposed fire, find out it didn't, debug for three hours.
After: the next-run simulator projects the next N fire times before you save. Tweak days, intraday step, cutoff, expiration — the projected list updates immediately. The schedule that ships is the schedule you saw.
Each type maps to a real scheduling intent a human can recognize without translation.
Run every N days from a start date. The workhorse for nightly jobs, daily exports, every-other-day batches.
Pick the days of the week by name: Monday, Wednesday, Friday. No 0-vs-1 indexing questions, no "does this shop use Sunday=0 or Sunday=7."
Monday through Friday. "Run on weekdays" as a single setting — no cheat sheet required.
Saturday and Sunday. For maintenance windows, heavy-batch windows, anything that only runs when humans aren't watching.
Pick days of the month by number: 1st, 15th, 28th. Months that don't have the requested day are handled explicitly — no silent skips.
"The last Friday of the month." "The second Tuesday." Business calendars are full of these — here they're a first-class option.
Hand-pick a list of specific dates. For holiday-driven schedules, one-off runs, or anything that doesn't fit a pattern.
Every schedule type can repeat within each active day. Step interval in minutes or hours, with a cutoff time that marks "stop for today." When the cutoff hits, the schedule rolls to the next active day and resumes.
Week type, days = Mon/Wed/Fri, start-time 08:00, step = 30 minutes, cutoff = 17:00. Fires 08:00, 08:30, 09:00 … 16:30, 17:00. Then nothing. Next active day (Wednesday) resumes at 08:00.
Weekday type, start-time 09:00, step = 1 hour, cutoff = 18:00. Fires hourly 09:00–18:00 Mon–Fri. Doesn't fire evenings, doesn't fire weekends. A shell script doing this is twelve lines of fragile logic; here it's three form fields.
Choose never-expires, expires-on-date, or expires-after-N-runs. Useful for time-limited campaigns, cleanup jobs scheduled at install, and migration scripts that should deactivate themselves.
Skip fires that arrive late because the engine was down or busy — no automatic catch-up on missed runs. Use it for schedules where a stale run is worse than no run.
The /schedule/test endpoint projects the next N fire times given a schedule's definition and an end date. Use it interactively — tune the days, the step, the cutoff, the expiration — until the projected dates are what you meant. Then save.
Catch a misconfigured schedule before it ships, not at 2 a.m. when the wrong job fires.
A schedule fires one or more linked jobs or one or more linked Monitors. The same calendar tick can fan out to both. Link many-to-many: one schedule can drive five jobs and three monitors; a single job or monitor can be on multiple schedules. Don't start from a blank calendar — install a Monitor from the InTouch AI hub, point it at your setup, and put it on a schedule. Find it and run it.
A multi-step DAG with dependencies, outputs piped between steps, optional if-task flow control, and full audit. The traditional path for any deterministic pipeline — ETL, report generation, scheduled cleanup, end-of-day batch.
A Monitor is a check + when primitive: it runs one tool to gather state (a stock price, an HTTP status code, a disk-space reading) and evaluates ordered when: arms against the result. The first matching arm fires actions — notify, run_tool, run_skill, run_jobfile. Optional ai: arm for fuzzy conditions. Author in YAML, install one from the InTouch AI hub, or describe one in your own language and let the AI assistant generate it.
Need to chain a tool conditionally inside a job rather than across schedule fires? Use the new if task — same arm grammar as Monitors but scoped to a single job's task list.
| Capability | InTouch AI | Windows Task Scheduler | Apache Airflow |
|---|---|---|---|
| Human-readable schedule types | 7 types by name | Partial | Schedule expressions |
| Visual next-run preview | ✓ | Partial | — |
| Intraday step + cutoff | ✓ | Partial | — |
| Relative days ("last Friday") | ✓ | — | — |
| Expiration rules | ✓ | Partial | Via DAG logic |
| On-time-only mode | ✓ | — | — |
| RBAC on schedule objects | ✓ (Dept/Enterprise) | OS perms | Partial |
| Alerts per schedule | ✓ across 8 channels | Email, limited | DAG-level |
| Schedule a single tool or skill | ✓ | — | DAG required |
The Python CLI intouch_import.py reads legacy schedule files — Linux scheduling files or Windows Task Scheduler XML exports — translates each entry into a native InTouch AI schedule, and (optionally) creates a runnable job that invokes the original command. Bulk migration is a one-shot script, not a months-long project.
Every line with a timing + command becomes a schedule + a runtimeenv job. Lines with timing only become schedules you can attach to an existing job.
Export tasks via schtasks /query /xml, point the CLI at the directory, get a native InTouch AI schedule per task.
The config era gave you a cron string and a prayer. InTouch AI gives you a readable schedule, a preview before you save, and an AI core behind it that reads the failure when a run breaks — "it broke, here's why, I fixed it." Download the free Personal edition and build your first schedule without touching a single asterisk.