// docs

Schedules

Schedule any script, runbook, installer, or S.E.N.T.R.I prompt to run once or on a repeating interval — and let the service run it while no one is logged in.

Creating a schedule

In Schedules, pick what to run (a script, runbook, installer, or a S.E.N.T.R.I prompt), the target host or group, a date and time, and a repeat interval. Add parameters if the run needs them, then enable it. Schedules can be disabled and re-enabled without deleting them.

Repeat intervals

Interval	Runs
One time	Once, at the specified date and time.
Every 5m – 12h	Repeating: 5m, 15m, 30m, 1h, 2h, 3h, 6h, or 12h.
Daily (24h)	Every day at the set time.
Weekly (7 days)	Every seven days.
Monthly (28 days)	Every 28 days.

How schedules run

Enabled schedules are registered with Windows Task Scheduler and executed by the ServerEngine automation service. That means they run headlessly — on time, whether or not the console (or any user) is signed in. Scripts, runbooks, installers, and S.E.N.T.R.I prompts all run the same way. Results and output land in the Logs just like interactive jobs.

Scheduled prompts

A scheduled prompt puts the agent on the clock: give S.E.N.T.R.I a goal in plain language, point it at a host or group, and the service runs it on your interval. The agent plans, calls the skills you allowed, and writes the whole conversation and every action to the Logs — so an unattended run is as traceable as a script.

A prompt row carries its own configuration rather than borrowing the chat's:

Field	What it does
Prompt	The goal, in your own words. The agent decides the steps.
Scope	The host or group it may act on. The agent is told about those hosts and no others.
Allowed skills	Ticked per schedule. Exactly these are offered to the run; leave the picker empty and every enabled skill is offered instead.
Provider & model	OpenRouter, a local Ollama, or a Claude Code session, and the model id. Never inherited from the chat — see below.
Effort	Reasoning effort for this run: Off, Low, Medium, High or xHigh.

A schedule keeps its own model

Changing the model in the chat does not change what a schedule runs on. This is deliberate: a schedule runs unattended for weeks, and inheriting whatever the chat happened to be set to meant one change could silently alter what every scheduled run costs and what it could do, without the row ever showing it. A row saved before you picked a model is pushed without one, and will ask you to re-save it rather than guess.

How long a run may take

A scheduled prompt is meant to finish its work, so there is exactly one limit on it: a max runtime you set yourself, under Settings → S.E.N.T.R.I → Schedules. It defaults to an hour.

Setting	Effect
Max runtime	The budget for a whole run. Default 60 minutes. Set it to zero — “as long as it takes” — and the run is not time-limited at all.
Checked between turns	The budget is tested between steps, never during one, so whatever the agent has in flight always completes rather than being cut off half-done.
One at a time	Scheduled prompts are serialized. A second one due while the first is still working queues in order rather than running alongside it.

There is no turn limit and no per-request limit. A long job that needs thirty steps is a long job, not a failure — the runtime budget is the only thing that will stop it.

The transcript is written into the job while the run is happening, so a scheduled prompt can be watched live in the console rather than only read afterwards. When it ends, the whole transcript is written to Logs\Sentri, stamped with the job ID.

Schedule states

State	Meaning
Enabled	Registered and waiting for its next occurrence.
Disabled	Kept, but not registered. Re-enable without recreating it.
Expired	A one-time schedule whose moment passed more than five minutes ago without running.
Processed!	A one-time schedule that has run. Its Windows task deletes itself, and the row is cleared with it.

Each schedule owns one Windows task

The task is named after the schedule's own ID, so editing a row or re-sorting the table cannot orphan it. If you delete that task yourself in taskschd.msc, ServerEngine treats it as intentional: the schedule is disabled rather than quietly recreated.

Writing the schedule is the approval

Approval-required skills are not skipped on a schedule, and they do not stop to ask either — there is nobody at 04:30 to answer. The approval moves instead to the moment you write the row: the Allowed skills you tick there are exactly what that run may call, and nothing else is offered to it. Treat that picker as the consent you would otherwise give at the prompt, and keep the scope tight before putting a prompt on a repeating interval.

Trigger schedules from the API

You can also create and run schedules through the REST API — useful for provisioning recurring jobs from infrastructure-as-code or another system.