InTouch 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 where most automation systems start — and where most teams hit their first surprise. 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 in InTouch doesn't only run jobs. It can execute a single tool directly (with inline parameters), invoke a skill by name, or run a YAML job-as-code file. The object you're scheduling doesn't need to be wrapped in a job just to get a trigger.
A multi-step DAG with dependencies, outputs piped between steps, and full audit. The traditional path.
Point at an installed MD or YAML skill by name. The schedule fires the skill with a fixed input. The AI assistant is not in the execution path — the skill's tools run deterministically.
One of the 42+ tools — SQL, HTTP, Anthropic, AWS — with parameters set at schedule-create time. No job wrapper, no ceremony.
| 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 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 schedule per task.
Download the free Personal edition and build your first schedule without touching a single asterisk.