HostStack Docs

Cron & Monitoring

Two HostStack primitives let you replace host-side crontabs and uptime scripts: cron services for single-shot scheduled jobs, and Workflows for multi-step durable tasks. Both run as containers on HostStack infrastructure — no SSH-into-a-VM, no missing-cron alerts on Monday morning.

When to use which

Cron service

Single command on a schedule. Renew certs, send a digest email, run a DB cleanup. Runs once per fire to completion and captures stdout/stderr. (No automatic retry — reach for a Workflow if you need retries.)

Workflow

Multi-step durable execution. Poll a URL → branch on result → fan out to webhook + email. Each step is retried independently and the run history is preserved for inspection.

Cron service: every 5 minutes, hit a health URL

Create a Cron service from the dashboard wizard. Pick a repo, set a 5-field crontab schedule, and define a start command. The service container runs the command once per fire and exits — each run is logged in Service → Executions with exit code, duration, and stdout/stderr.

Start command (set in Service → Settings)

curl -fsS https://api.example.com/health \
  || curl -fsS -X POST -H 'content-type: application/json' \
       -d '{"text":"prod /health is down"}' \
       "$SLACK_INCOMING_WEBHOOK"

Set the schedule (e.g. */5 * * * *) and the SLACK_INCOMING_WEBHOOK env var on the same service page. Mark the env var as a secret so it stays masked in the API response and dashboard.

Workflow: scheduled container with retries

A Workflow is a single Docker image plus an optional cron schedule. The workflow engine fires it on schedule (or on demand), waits for it to exit, retries up to maxRetries times if it fails, and timestamps every run in the run history. Reach for it when you want a job to live next to your stack but not inside any one service container.

Create a workflow via the API

curl -X POST https://hoststack.dev/api/projects/${TEAM_ID}/${PROJECT_ID}/workflows \
  -H "Authorization: Bearer hs_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "projectId": '${PROJECT_ID}',
    "name": "prod-monitor",
    "image": "curlimages/curl:latest",
    "command": ["-fsS", "https://api.example.com/health"],
    "schedule": "*/5 * * * *",
    "timeoutSec": 60,
    "maxRetries": 3
  }'

Workflows are billed per execution-second; idle time between fires is free. Failed runs surface in the Workflows tab and emit a workflow.failed notification. Re-run from the run-detail page without redeploying.

Migrating a host crontab

If you're running a /etc/cron.d/ stanza on a VPS like:

bash

*/15 * * * * root /usr/local/bin/snapshot-database.sh
0 4 * * * root /usr/local/bin/rotate-logs.sh
*/5 * * * * monitoring /usr/local/bin/check-prod.sh

Each line maps to one HostStack cron service. Move the script body into a small repo (or commit alongside your app), point the cron service at it, and set the schedule. The host VPS becomes pet-free; new alerts on missing crontabs are caught by HostStack's deploy-failure + cron-execution-failed events instead of "wait, didn't this fire last Tuesday?".

Existing platform alerts you get for free: configure them in Settings → Notifications. Default-on critical events include cron.execution_failed (when a fire's exit code is non-zero) and workflow.failed.