Inquir Compute logoInquir Compute
Use case

Serverless cron jobs on the same platform as your APIs

Run serverless cron jobs as scheduled pipelines with run history next to HTTP invocations, retries you can tune, and shared secrets/logs so nightly work uses the same functions as your REST API endpoints.

Last updated: 2026-04-20

Direct answer

Serverless cron jobs on the same platform as your APIs. The same function ID can power an HTTP route and a scheduled pipeline step—no duplicate code trees for serverless cron jobs.

When it fits

  • Nightly ETL
  • Certificate or token rotation
  • Periodic polling integrations

Tradeoffs

  • Timers improve fire reliability but do not give you dependency isolation or shared secrets/logs with HTTP handlers.
  • You still need one place for retries, run history, and alerts—otherwise serverless cron jobs stay invisible next to production APIs.

Why host cron and crontab fail serverless cron jobs

Serverless cron jobs still fail silently when logs live only in root mail or ad-hoc scripts.

If you keep schedules only on a VPS, you own packaging drift, secret sprawl, and “who restarted cron?” debugging—every outage becomes SSH archaeology.

Crontab entries drift outside versioned deploy workflows, so no one knows which binary ran last night.

Overlapping runs corrupt shared state without skip-if-running guards—scheduled pipelines need the same rigor as webhook processors.

Why timers alone do not fix serverless cron jobs

Timers improve fire reliability but do not give you dependency isolation or shared secrets/logs with HTTP handlers.

You still need one place for retries, run history, and alerts—otherwise serverless cron jobs stay invisible next to production APIs.

One platform for APIs and serverless cron jobs

The same function ID can power an HTTP route and a scheduled pipeline step—no duplicate code trees for serverless cron jobs.

Cron strings are validated when you save the pipeline; the worker tracks nextRunAt per pipeline so edits reschedule cleanly and run history stays queryable.

Cron scheduling, retries, and observability

Cron validation

Schedule expressions are validated at save time so malformed entries fail early.

Worker cadence and overlap handling

Design minute-scale workloads and add skip-if-running guards for long jobs.

Execution history

Answer “did the job run?” without grep—run history sits with HTTP executions.

Run alerts

Hook monitoring to failure rates or duration SLOs for serverless cron jobs.

Migration checklist

Move one recurring task safely from shell to scheduled pipeline execution.

1

Extract handler from shell script

Move script logic into a versioned function.

2

Test manual invoke + attach schedule

Validate outputs first, then add a schedule trigger.

3

Add overlap guard + run alert

Prevent concurrent corruption and surface failures immediately.

Common cron job patterns

Scheduled handlers receive pipeline metadata on event. Two common patterns: watermark-based incremental sync (safe to retry) and report generation with fan-out.

jobs/incremental-sync.mjs (watermark pattern)
export async function handler(event) {
  // Read cursor from env so re-runs do not re-process old records
  const since = process.env.SYNC_CURSOR ?? new Date(Date.now() - 86_400_000).toISOString();
  const records = await source.fetchUpdatedSince(since);
  await destination.upsertBatch(records); // idempotent by record ID
  const newCursor = records.at(-1)?.updatedAt ?? since;
  // Update cursor in your config/store for next run
  return { synced: records.length, cursor: newCursor };
}
jobs/nightly-report.mjs (report + fan-out)
export async function handler(event) {
  const rows = await buildReport();
  await storage.upload(rows, { key: `reports/${new Date().toISOString().slice(0, 10)}.csv` });
  // Fan out — each recipient gets a separate pipeline step
  await Promise.all(
    recipients.map((r) => global.durable.startNew('send-report', undefined, { recipientId: r.id, rowCount: rows.length })),
  );
  return { rows: rows.length, notified: recipients.length };
}

Choose this when…

When this works

  • Nightly ETL
  • Certificate or token rotation
  • Periodic polling integrations

When to skip it

  • Sub-second periodic tasks—validate platform timers first

FAQ

What if a cron run takes longer than the interval?

Use idempotency keys, distributed locks, or skip-if-running guards inside the handler so overlapping firings do not corrupt shared state.

How is this better than crontab on a single machine?

You get versioned lambda bundles, container isolation per invoke, persisted invocation records, and the same secrets model as HTTP functions—plus multi-step graphs when one schedule should fan out.

Which timezone applies to cron expressions?

Document the timezone your team expects (often UTC for backends); align schedules with daylight-saving rules if you target wall-clock business hours.

Inquir Compute logoInquir Compute

The simplest way to run AI agents and backend jobs without infrastructure.

Contact info@inquir.org

© 2025 Inquir Compute. All rights reserved.