Schedules Preview

A schedule runs one of your scripts at fixed times, cron style, instead of waiting for a file event. Nightly cleanups, hourly pickups from another storage, a weekly report: anything a script can do, a schedule can do on time.

Schedules run on your Connector, like everything else in Automation. Nothing about them travels to SFTP.cloud.

Creating one

Automation, then Schedules, then New schedule.

Field	Notes
Name	How the schedule appears in lists and run history
Description	For your own benefit
Schedule	A standard five field cron expression, or a descriptor
Script	Which script to run; the script must be enabled to actually run
Parameters	Name and value pairs the script reads with Param("name")
Enabled	A disabled schedule keeps its settings and fires nothing

The Check button next to the schedule field parses the expression and shows its next fire times, so you see what the expression means before saving. An invalid expression is refused at save, never discovered later by silence.

The expression

Five fields: minute, hour, day of month, month, day of week.

Expression	Meaning
*/15 * * * *	Every fifteen minutes
0 2 * * *	Every day at 02:00
0 8 * * 1	Mondays at 08:00
@hourly	On the hour, every hour
@daily	Every day at midnight

If a run is still going when the schedule fires again, that occurrence is skipped, never queued behind it.

What a scheduled script sees

A scheduled run has no user session and no triggering file, so the event bound parts of the scripting surface are absent: there is no GetCurrentVFS(), no EventCtx(), and no Session object. Instead the run gets:

Global	Meaning
RunID	This run's unique id
Param(name)	The value of a parameter authored on the schedule
HaltSignalReceived()	Whether a halt was requested; poll it in long loops
WaitForHaltSignal()	Blocks until a halt is requested

Storages are reached by name: GetVFSByName() hands the script any of this Connector's storages, and new VirtualFS(...) builds ad hoc ones. The secrets, SendMail() and Telegram surfaces work exactly as they do in event handlers.

// Move everything from the staging storage into the archive, nightly.
var staging = GetVFSByName("Staging");
var archive = GetVFSByName("Archive");
var listing = staging.ReadDir("/outbox", SortByTime, SortAsc);
if (!listing.Ok()) {
    Log.Error("cannot list staging: " + listing.ErrorMsg());
    Exit(1);
}
listing.Infos().forEach(function (item) {
    if (HaltSignalReceived()) Exit(0);
    if (item.Type === "dir") return;
    var resp = staging.MoveToVFS("/outbox/" + item.Name, archive, "/" + Param("year") + "/" + item.Name);
    if (!resp.Ok()) Log.Error("move failed for " + item.Name + ": " + resp.ErrorMsg());
});

Runs, logs, and halting

Runs (top right on the Schedules page) lists recent and live runs. Every run writes its own log file, and a live run's log can be watched as it happens; the viewer keeps up line by line.

Run now fires a schedule immediately, regardless of its timetable, and opens its log.

Halt asks a live run to stop. Halting is cooperative: the script decides when to stop, by checking HaltSignalReceived() or waking from WaitForHaltSignal(), so its cleanup code gets to run. The hard backstop is the run timeout below; a script that ignores the halt is stopped when the timeout expires.

Settings

Settings, then Scheduler.

Setting	Meaning
Run scheduled scripts	The master switch; off pauses every schedule without deleting anything
Concurrent runs	How many runs may execute at once; applies at the next service start
Run timeout	The hard wall clock limit of one run
Run history retention	Finished run records and their logs older than this are removed daily