Cron & Monitoring

Uptime monitoring is built in: HostStack requests your service’s public URL on a schedule and alerts your team when it stops answering — no service to write or run. Beyond that, two primitives replace host-side crontabs and scheduled 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.

Uptime checks (built in)

Turn this on in Service → Settings → Health Check → Uptime monitoring. HostStack requests your service’s primary domain on the interval you set, and after a number of consecutive failures you choose, it raises an alert through your existing notification channels — Slack, Discord or email — and records it in the alerts feed. It clears itself when the service starts answering again.

This is not the same thing as the health check above it, and the difference is the point. The health check runs on the server, against the container, while a deploy is going out. An uptime check runs from outside, against the URL your users open, forever — so it also catches DNS, TLS, and routing problems, and a service that accepts the connection and then never replies.

A site we don’t host can be checked too. Register it under Site Analytics, prove the domain is yours with the TXT record shown there, then turn on a check against the site instead of a service — hoststack uptime set --site <site-id> --path /. Of the three things on this page, this is the one an outside site cannot do for itself: a script tag and an error POST both run on your own server, but a probe has to come from somewhere else to mean anything. The proof is required because the check makes HostStack fetch that hostname on a schedule, from our IP — we will only do that for a name you have shown is yours.

An uptime check answers “is it answering?”. For “what threw, where, and how many people hit it”, see Error Tracking — which also turns any grouped exception into an agent task in your dev box.

What counts as a failure

Any status code other than the one you expect, or no answer inside your timeout. Redirects are not followed — if a 301 is the correct answer, set that as the expected status.

When checks pause themselves

While a service is suspended, mid-deploy, or has no domain yet — those are not outages. Services that sleep when idle are left alone too, since checking one would wake it every time.

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.

Alerts can also be delivered as browser push notifications, so a crash-loop reaches you with the dashboard closed. Enable it per device under Settings → Notifications. On iPhone and iPad you must first install HostStack to the Home Screen (Share → Add to Home Screen) — iOS only permits push for installed web apps. Push is best-effort and routed through your browser vendor's push service, so keep email enabled for anything you can't afford to miss.