Migrating from system cron

#Why move off system cron

System cron is a fine tool with a narrow job: run a command on a machine at a time. It does not know whether the machine is alive, whether the previous run finished, whether the command succeeded, or whether anyone should be told. Most teams discover these gaps in production, usually at 3 a.m.

Tend replaces the machine-bound crontab with a hosted schedule that calls an HTTP endpoint you control. You keep the logic, we keep the clock. In exchange you get automatic retries with backoff, a concurrency limit so slow runs don't pile up, searchable run logs and signed delivery of results to a webhook.

• No single point of failure. A rebooted or replaced server no longer skips scheduled work.
• Failure is visible. Every run has a status, an HTTP response code and captured output metadata.
• Retries are declarative. 5 attempts by default, up to 25, instead of a shell loop wrapped around curl.
• Multiple instances are safe. Scaling your app to three replicas no longer triples your nightly job.

#Mapping crontab concepts to Tend

A crontab line is a schedule plus a command. In Tend, the schedule stays a schedule, and the command becomes an HTTP endpoint that performs the work. If your existing job is a script, the easiest path is a small authenticated route in your application that invokes it.

#Creating your first schedule

Take a typical crontab entry: a nightly invoice reconciliation at 02:30 Mountain time, running a script on a single server.

# /etc/cron.d/billing
CRON_TZ=America/Denver
MAILTO=ops@northfork.example
30 2 * * * billing /opt/billing/bin/reconcile.sh >> /var/log/reconcile.log 2>&1

The Tend version points at an endpoint on your service and names the schedule. Names are unique per environment, so a second create with the same name returns 409 schedule_name_taken, which is a feature: it prevents duplicate migrations from doubling the work.

curl -X POST https://api.tendcomputer.com/v2/schedules \
  -H "Authorization: Bearer tnd_live_9fK2xQ7mVb3LpR8dWc1Zh" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: migrate-reconcile-2026-04-22" \
  -d '{
    "name": "nightly-invoice-reconcile",
    "cron": "30 2 * * *",
    "timezone": "America/Denver",
    "url": "https://api.northfork.example/internal/reconcile",
    "payload": {"scope": "invoices"},
    "concurrency": 1,
    "retry": {"max_attempts": 5, "base_seconds": 10, "cap_seconds": 3600},
    "region": "us-west"
  }'

schedule = client.schedules.create(
    name="nightly-invoice-reconcile",
    cron="30 2 * * *",
    timezone="America/Denver",
    url="https://api.northfork.example/internal/reconcile",
    payload={"scope": "invoices"},
    concurrency=1,
    retry={"max_attempts": 5, "base_seconds": 10, "cap_seconds": 3600},
    region="us-west",
)
print(schedule.id)  # sch_01J9C2VN5R8H3K7YQ4WTB6DXMA

const schedule = await client.schedules.create({
  name: "nightly-invoice-reconcile",
  cron: "30 2 * * *",
  timezone: "America/Denver",
  url: "https://api.northfork.example/internal/reconcile",
  payload: { scope: "invoices" },
  concurrency: 1,
  retry: { maxAttempts: 5, baseSeconds: 10, capSeconds: 3600 },
  region: "us-west",
});
console.log(schedule.id); // sch_01J9C2VN5R8H3K7YQ4WTB6DXMA

schedule, err := client.Schedules.Create(ctx, &tend.ScheduleCreateParams{
    Name:        "nightly-invoice-reconcile",
    Cron:        "30 2 * * *",
    Timezone:    "America/Denver",
    URL:         "https://api.northfork.example/internal/reconcile",
    Payload:     map[string]any{"scope": "invoices"},
    Concurrency: 1,
    Region:      "us-west",
})
if err != nil {
    log.Fatal(err)
}
fmt.Println(schedule.ID)

#Semantic differences that will surprise you

Cron expressions look the same, but the surrounding behavior is not. Read this section before cutting over anything that matters.

• Success is defined by your endpoint. Cron treats exit code 0 as success. Tend treats a 2xx response as success. Return a 2xx only when the work is done or durably queued, otherwise Tend will record a success that isn't one.
• Timeouts are real. A run may execute for at most 15 minutes. Cron has no such limit, and long-running scripts often depend on that. For long work, return quickly and process asynchronously, then report completion by another means.
• Delivery is at least once. Retries mean your endpoint can see the same run more than once. Make handlers idempotent, keyed on the run ID sent in the request headers.
• Missed runs are not silently replayed forever. If a schedule is paused and resumed, Tend fires the next occurrence rather than back-filling every one you missed.
• Daylight saving time behaves per IANA rules. A schedule at 02:30 in America/Denver skips the nonexistent hour on the spring transition and runs once on the fall transition. If exact wall-clock behavior matters, prefer a schedule in UTC and convert in your handler.

#A safe cutover plan

Do not delete the crontab entry on the same day you create the schedule. The safest path is a short overlap with a dry-run period, using the development environment first. A tnd_dev_ key creates schedules in a separate environment that cannot touch production data.

• Create the schedule with a tnd_dev_ key and point it at a staging endpoint. Confirm it fires at the expected local time.
• Make the target endpoint idempotent, or add a guard so a second invocation within the same window is a no-op.
• Create the production schedule with a tnd_live_ key while the crontab entry is still active. Run both for at least one full cycle, comparing results.
• Comment out the crontab entry, do not delete it. Keep it for a week, then remove it.
• Add an alert on failed runs before you walk away. See the monitoring guide for how.

# Trigger an immediate run to verify the endpoint before the first scheduled tick
curl -X POST https://api.tendcomputer.com/v2/schedules/sch_01J9C2VN5R8H3K7YQ4WTB6DXMA/trigger \
  -H "Authorization: Bearer $TEND_API_KEY"

# Then inspect the resulting run
curl "https://api.tendcomputer.com/v2/runs?schedule_id=sch_01J9C2VN5R8H3K7YQ4WTB6DXMA&limit=1" \
  -H "Authorization: Bearer $TEND_API_KEY"

#Errors you may see during migration