OverviewQuickstartdbt CompatibilityThe Style Guideprofiles.ymlsources.ymlConfigurationSupported Databases

DVT SCHEDULER

PORT :46106 · STARTS WITH dvt serve · WRITES ANSWER LOOPBACK ONLY

Your dvt commands on a cron — or saved with no schedule at all, waiting for you. The scheduler is deliberately an honest local scheduler: jobs fire while it runs (it comes up with dvt serve), it is not a hidden daemon, and everything it does is visible — history, logs, and honest per-run feedback.

Starting and stopping

dvt serve                    # the suite, scheduler included
dvt serve -s scheduler       # just the scheduler
dvt kill -s scheduler        # stop just the scheduler
dvt kill --exclude scheduler # stop everything EXCEPT the scheduler
                             # (the UIs go down, the schedule keeps firing)

No serve, no schedule: a job whose minute passes while the scheduler is down is missed, not queued. For servers this is what you want — the process is under your supervision, not hiding behind an init system.

Creating jobs

A job is a plain dvt command plus a schedule. Commands are verb-whitelisted — run, build, test, seed, snapshot, compile, docs, sync, retract, clean — executed as arguments, never through a shell. Shell metacharacters in arguments are refused at save time, and duplicate job names are rejected.

  • schedules are dropdowns — presets (hourly, daily @ 06:00, weekly, every 15 minutes) or a custom cron composed from five labeled dropdowns — minute, hour, day of month, month, weekday. Nobody hand-types */15 6 * 7 5.
  • manual-only mode — flip the schedule mode to 'manual only' and the job has no cron at all: a saved, validated command you fire with RUN NOW whenever you need it. Its card says 'run it when you need it'.

Running and controlling

  • RUN NOW — fires any job immediately, scheduled or manual — recorded in history with trigger 'manual'.
  • overlap guard — a cron tick that would overlap a still-running previous run records 'skipped' instead of stacking two builds on top of each other.
  • KILL — every running job shows a KILL button. Jobs run in their own process group, so KILL terminates the entire tree — dvt and its Sling children — SIGTERM first, SIGKILL five seconds later if it lingers. History records 'killed by user'.
  • ENABLE / DISABLE — per scheduled job (manual-only jobs have nothing to disable).
  • the master switch — SCHEDULE: ON/OFF pauses all cron firing project-wide — job definitions untouched, RUN NOW and KILL still work, a banner states exactly what's paused. For maintenance windows and for teams who use the scheduler purely as a saved-jobs launcher.

Logs — feedback, not dumps

Every job has a LOGSpage: all runs newest-first, each expanding into parsed feedback drawn from dvt's own output markers:

  • the result line — PASS / WARN / ERROR / SKIP out of TOTAL, straight from the run.
  • WENT WELL — models created, seeds loaded, row counts — the green section.
  • WARNINGS — everything dvt warned about, deduplicated.
  • ERRORS — the actual failure messages with their DVT codes — the failing model and the exact reason, not a stack trace hunt.
  • the full raw log — one click away; complete logs live in ~/.dvt/logs/jobs/<job>-<timestamp>.log.

What dvt kill does to running jobs

dvt kill stops the scheduler — UI and cron brain together, so nothing fires afterwards. But a job in flight is its own process and dvt kill spares running dvt work by doctrine: your nightly build finishes even if the suite went down halfway through. Its history entry is recorded at start, so nothing vanishes; if the scheduler died mid-run, the next boot marks the entry interrupted — the job process ran on without it (check its log). Only dvt kill --force terminates running work.

← The App SuiteThe Hub →