June 12, 2026

Cron schedules vs folder watchers: picking the right MFT trigger

Every MFT migration replays the same architecture debate: poll on a schedule or react when a file lands. Both patterns work; choosing wrong creates missed SLAs, duplicate transfers, or audit gaps when nobody can explain why a job ran twice at 2:07 a.m.

Cron schedules — predictable, batch-friendly

Cron jobs excel when partners publish on known windows — "files ready by 06:00 UTC, we pull at 06:15." You control concurrency, retry policy, and downstream sequencing. Auditors like cron because job history maps cleanly to calendar entries: who scheduled it, what fired, what transferred. Downside: latency. A file that lands at 06:01 waits until the next slot unless you tighten the schedule and accept more empty polls.

Folder watchers — event-driven, latency-sensitive

Watchers trigger on create or modify events in object storage or SFTP directories. Use them when partners drop files unpredictably and minutes matter — fraud feeds, inventory snapshots, clinical results. Latency drops; complexity rises. Partial uploads can fire early unless you debounce on stable file size or use a .ready suffix convention. Duplicate events from storage notifications need idempotent job design.

Compliance and evidence

Both triggers must write the same per-transfer audit record: trigger type (scheduled vs event), source path, file hash, outcome. Questionnaires increasingly ask how you prevent duplicate processing — document deduplication keys and dead-letter handling. A watcher without audit trail is a shadow script; a cron job without alerting is a silent failure.

Hybrid pattern most teams need

Run cron for partner bulk feeds (nightly GL extracts) and watchers for operational hot paths (chargeback files). One MFT platform should support both without separate products. Size monthly volume and job count with the transfer volume estimator so you do not under-provision event-driven peaks.

xEvolve supports cron schedules and folder-triggered jobs in the same Environment — one audit log, one ops console, no bolt-on scripting host.