Inquir 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.

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.

Job skeleton

Scheduled runs invoke the same handler with pipeline metadata on event (payload, pipeline, step, etc.). Return JSON for logs and downstream steps.

jobs/report.mjs
export async function handler(event) {
  const rows = await buildReport();
  await upload(rows);
  return { rows: rows.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

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

Contact info@inquir.org

© 2025 Inquir Compute. All rights reserved.