Use case · Operations
Servers, deploys and overnight jobs that finish on their own.
Operations work is long, fiddly and fails at 3 a.m. Sentinel runs it on your own machines, cures its own failures in order, and leaves an audit log of every command so you can read the night back in the morning. Nothing runs that your rules do not allow. The morning check is reading a log, not rebuilding the night.
$ sentinel run "deploy main to the mini, health-check, roll back on failure" git pull · 14 files changed deploy/mini.sh … ok 3m12s health: model server ok · disk 61% · 2 MCP servers up self-heal: one MCP server came up on the second try Kept the deploy · nightly review scheduled 03:00
How it fits together
Three pieces, one platform
The same model, the same rules and the same runtime, pointed at this kind of work.
Runs on your machines
Shell, files and services on the servers you own, over your private network. No inbound ports, no third-party runner.
Cures failures in order
Retry, compact, reroute to another model. A crashed tool server comes back with backoff. One line of notice, then the job continues.
Leaves an audit log
Every command, its device, its result and its duration, kept on your side and readable in the morning.
From the logs
Straight into the runbook your team reads
Incident notes, health reports and change logs come out as files your team already reads, written at the end of every run, with the command and the device behind each line.
Across the work
The jobs a chat window cannot run
Deploys, monitoring and scheduled work all need a shell on a machine you own. Switch tabs to see each one.
User
Assistant
Handed back · nothing done
User
Sentinel
deploy-2026-10-12.md - git pull: 14 files changed - deploy/mini.sh ok in 3m12s health.md - model server, disk, 2 MCP servers ok audit.log - 4 commands, each with its device and result
Audit log · 4 commands
User
Assistant
Handed back · nothing done
User
Sentinel
status.md - 12 services online, 1 errored (worker) - worker ran out of memory at 1.9 GB fix.md - restarted worker, watched 5 min: stable - capped the import batch to stop a repeat audit.log - 3 commands, all on the mini
Audit log · 3 commands
User
Assistant
Handed back · nothing done
User
Sentinel
nightly-backup.job - 03:00 daily: dump, verify, rotate (keep 14) - notify on failure only dry-run.md - finished in 41 s, archive verified - survives restarts and reboots schedule - first real run tonight at 03:00
Scheduled · survives restarts
$ sentinel run "nightly: back up, verify, deploy if green" Scope: the mini · owner rules: shell, deploy, pm2 backup … ok 2m41s · verify … ok deploy/mini.sh … ok 3m12s self-heal: one MCP server retried once, up Wrote night-2026-10-12.md · 37 commands in the audit log
In practice
A night you can read back
Every command, every retry and every decision is written down, so the morning check is reading a log, not reconstructing what happened.
FAQ
Questions, answered
Does it need open ports on my servers?
No. It reaches your machines over your own private network, the way you already do.
What stops it from running something dangerous?
Your rules. Allowed devices and commands are set per machine, and spend caps and the audit log sit outside the model where a prompt cannot change them.
What happens when a step fails?
It classifies the failure and tries the cures in order: retry, compact, reroute. If nothing works it stops cleanly and tells you exactly where.
Can it run while my laptop is closed?
Yes. Long jobs run on your always-on machine and resume from the last finished step after a restart.
How is it priced?
Free to start. Long tasks and scheduled jobs are included from Pro at $20 a month.