Skip to content
← Docs

Scheduled tasks

Schedule a command, script or resource action to run on a host at a chosen time — once, or on a recurring schedule. Every run is RBAC-scoped and captured for audit, exactly like a live session.

Scheduled tasks are managed from the Scheduled tasks page in the console at app.subnomic.com.

Nothing runs on your laptop: when a task is due, Subnomic hands it to the target's agent, which executes it inside your network and reports the result back.

What you can schedule

  • Host command / script — any shell command or script on a host agent (e.g. a nightly backup, a cleanup job, a deploy script). Capture stdout/stderr, exit code and duration.
  • Resource action — operate on a real Docker or Kubernetes resource: restart, start / stop (Docker containers), scale to N replicas, or update image — on a Kubernetes workload, a Docker swarm service, or a Docker container.

Create a scheduled task

  1. Go to Scheduled tasks → New task and give it a name.
  2. Pick the type and the target agent — a host agent for a command, or a Docker / Kubernetes agent for a resource action. The agent is the executor; the task is delivered to it.
  3. Fill in what to run: the command (plus optional run-as user, timeout and working dir), or — for a resource action — pick the resource and the operation, then any operation fields (replicas, or container + new image).
  4. Set when: a recurrence, a time, and a timezone (see below). Save. The task shows its next run in your timezone.
The target is an agent, not a server — agents are what execute work. For a host command you pick the host agent (shown by its server's name); for resource actions you pick the Docker / Kubernetes agent that manages that cluster or daemon.

Timezones & daylight saving

You choose a wall-clock time and an IANA timezone (e.g. Europe/Istanbul). The task fires at that local time — and it keeps firing at that local time across daylight-saving changes, with no drift. A "daily at 21:00 Europe/Istanbul" task runs at 21:00 local every day, whether that maps to a different UTC instant after a DST shift or not.

Under the hood everything is stored in UTC. The next run is always recomputed as the next matching wall-clock time in your timezone, then converted to UTC — never by adding a fixed 24 hours, which is what would cause an hour of drift after a spring-forward / fall-back.

Pick the timezone deliberately. If you mean "09:00 in the office", choose the office's IANA zone — not UTC. The form defaults to your profile timezone.

Recurrence

  • Once — a single run at a date + time you pick (it won't repeat).
  • Daily — every day at the chosen time.
  • Weekly — on a chosen weekday at the chosen time.
  • Monthly — on a chosen day-of-month at the chosen time.
  • Custom (cron) — a standard 5-field cron expression, interpreted in your timezone. For example 0 21 * * 1-5 = 21:00 on weekdays.

Update an image on a schedule

Choose Resource action, pick the resource, set the operation to Update image, and enter the new image reference. At run time the agent operates on the live object — it does not replay a manifest captured when you created the schedule, so it always applies to whatever is currently running:

  • Kubernetes (Deployment / StatefulSet / DaemonSet / ReplicaSet) — also pick the container; the agent patches that container's image and waits for the rollout.
  • Docker service — the agent swaps the image on the live service and swarm rolls the tasks (no container field needed).
  • Docker container — the agent pulls the new image and recreates the container with the same config (brief downtime).
Resource:   Deployment/web · production
Operation:  Update image
Container:  web
Image:      registry.example.com/web:2.4.0
Schedule:   Once · 2026-06-10 02:00 · Europe/Istanbul

Runs, history & audit

Each time a task fires it creates a run you can inspect under the task's Runs view: when it started, its status (succeeded / failed / running / pending), when it finished, and any error. For host commands the captured stdout / stderr and exit code are kept with the run. Creating, editing, enabling/disabling, running and every fire are written to the activity log.

  • Run now — fire a task immediately, out of band, without changing its schedule.
  • Enable / disable — pause a schedule without deleting it; re-enabling resumes from the next occurrence.
  • Delete — removes the schedule; past runs are kept for audit.

Guardrails & offline agents

  • A host command — or a Docker / Kubernetes resource action — that a guardrail would deny or require_approval cannot be scheduled. An unattended run can't be approved interactively, so it's rejected when you save (target type server for commands, kube / docker for resource actions).
  • Guardrails are re-checked at run time. If a rule added later now blocks the command or action, that run is skipped and logged, and the schedule advances to its next occurrence.
  • If the target agent is offline when a task is due, the run is queued and delivered when the agent reconnects (the same way manual tasks behave).
Scheduling is highly available: the due-task loop runs on every backend replica and claims each due task with a database lock, so a task fires exactly once even with several replicas. After downtime it fires one catch-up run and resumes — it does not replay every missed occurrence at once.

Permissions

scheduled_task.read scheduled_task.create scheduled_task.update scheduled_task.delete

create also covers Run now; update covers enable / disable. A run executes with the same envelope as an interactive session on that target, and on Linux a host command can run as a provisioned per-operator user.