▾ How do I use this

Toggle — saves immediately to schedule.json
Cron field — auto-saved on focus-out; hint shows plain English; red border = invalid
⚙ Cog — opens settings panel: script header + matching README/Manual sections + config fields
Script name — click navigates to the matching entry in the Orch tree (right panel)
Run — fires script immediately; resets the cron timer so next fire is one full interval later
Dry Run — same as Run but passes --dry-run; no changes written to disk
Log — opens script log here; auto-scrolls; use Search box to filter/highlight lines
Stop — SIGTERM → 3 s → SIGKILL; clears stuck lock files
Verbose — appends --log flag for per-item detail output
Cancel — discards changes and returns here; file is never touched until Save
⚡ Array events — set any cron field to array_start or array_stop; badge appears; fires on Unraid array start/stop; works on any orch or custom script
Arrange — drag scripts between orchs; drop to right panel removes from orch; Save Arrangement commits to master.conf
+ Folder — collapsible subfolder in Custom Scripts; drag scripts in
Suggested cron — click the cron code badge in the Orch tree to apply and save instantly
Status dot (tree) — green/orange/red ● = last run ok/warn/error; dim = never run; hover for detail
Cron Calculator — type an expression or plain English; shows description + next 5 fires; Apply pushes to last-focused cron field
Recent Activity — last 24 runs; click a row to open that log; auto-expands on errors
Recent Errors — last error per script (7 days); click to open log; auto-expands on new errors
Advanced — top-right button, turns blue; ⚙ shows enriched view (header + docs + config); raw conf editing unlocked
Log search — filter box in toolbar when log is open; highlights matches, dims others
← Scheduler Info — returns here from any log, editor, conf, or script view
Orchestrator & Child Behaviour
Orch ON — sole trigger; cron fires the orch; it calls children in sequence
Orch OFF — never runs automatically; children suppressed; each can get its own standalone cron
Child (orch ON) — toggle comments/uncomments the script in master.conf
Child (orch ON, no array) — orch hardcodes the call; toggle is display-only
Child (orch OFF) — enter a cron to run it standalone
Rsync badge — toggle writes TIER_RSYNC_ENABLED directly to master.conf
Rsync (orch OFF) — fill location + standalone cron + Save; both required for independent firing

▾ Next Runs

calculating…

▸ Cron Calculator

▸ Recent Activity

▸ Recent Errors

▸ Active Locks

▸ Partner —

▸ Disabled on this host

▾ Fallback

Not enterprise HA. No SLAs, no quorum nodes, no guaranteed uptime — don't put your billing system on this.

What it is: mutual automatic failover between two independent unRAID servers. When one goes down the other starts its containers, cuts over DNS, and keeps users online. When it comes back, everything hands back in the correct sequence — DDNS stops, containers stop, rsync writeback runs, containers start on the primary, primary DDNS starts last — so users hit the returning server only after it's actually ready.

Built from scratch. Refined through a year of production testing. The DDNS sequencing and handback order were the hardest parts to get right. Both directions are exercised regularly with fallback_test.sh.

▸ How it works

Varaverk owns the cron layer. schedule.json stores every orchestrator's enabled state, cron expression, and log setting. When you save, the plugin rebuilds /etc/cron.d/varaverk — one entry per enabled orchestrator. That's all cron knows about.

Orchestrators are the only scripts with cron schedules. Each one reads its SCRIPTS list out of master.conf and runs each child in sequence. The children do the actual work. The orchestrator controls the order and the timing. A child failure stops the chain.

master.conf is the per-host control plane. Comment out a line to disable that script on this host without touching any code. Both servers run the same repository — different master.conf comments produce different behaviour per machine.

Children only get their own cron when their orchestrator is OFF. When the orch is on, it owns the timing completely.

common.sh provides the shared runtime every script sources: acquire_lock(), log_msg(), info(), success(), warn(), error(). Lock files live in /tmp/varaverk_locks/. acquire_lock() exits cleanly if a prior run is still in progress — nothing piles up.

Logs are written per script to the appdata path. The Log button shows the latest run. Verbose mode passes --log for per-step detail.

Array events bypass cron entirely. array_start fires when Unraid brings the array up; array_stop fires before shutdown. array_started handles all post-start setup in sequence; array_stopping handles the graceful teardown.

The watchdog tier runs every 15 minutes as a single-pass chain: resource_watchdog frees memory pressure first, docker_watchdog restarts down containers into that headroom, system_watchdog checks storage/WebGUI/network, stability_watchdog reboots as a last resort. The order matters — restarting containers before freeing memory just restarts them into the same pressure.

▸ This started as...

One script. A few lines — checking whether a container was running and restarting it if not. Backgrounded through User Scripts, sleeping a minute between checks, essentially forgotten. It did its job.

Then a conversation with a buddy: wouldn't it be cool if it emailed when something crashed? Sure, added it. Wouldn't it be cool if it handled more containers? Easy — grow the list. Wouldn't it be cool if both servers stayed in sync automatically so neither of us had to remember to do it manually?

That one took a while.

Order started to matter. Freeing memory before attempting container restarts meant the containers actually stayed up. Sync had to happen before the media database refresh, not after. Watchdogs couldn't block each other. The big loop that tried to do everything started breaking into pieces — one piece per job, and a sequencer that knew which piece went first.

master.conf became the control plane: one file, two different sets of comments for two different hosts. Same codebase, different behaviour per machine. The orchestrator pattern came out of not wanting to duplicate logic.

By the time the User Scripts plugin couldn't clearly show what was actually scheduled, whether something was running, or why a sync had quietly stopped working two weeks ago — the interface became the next thing to build.

Varaverk started as a status table and a schedule editor. The scheduler became the main thing. The monitor followed.

Still the same two servers, two households, the same media stack running itself. The scripts just grew up around it.

▸ Varaverk