Use case

Cron-style jobs as scheduled pipelines, not mystery shell

Cron on a pipeline trigger—same functions as HTTP, one history stream for every run.

Situation

Where crontab rots

Mail-to-root is disabled, so jobs fail silently. Scripts live on one box, never in git, and nobody knows which version ran last night.

Overlapping jobs step on the same files. New hires learn the schedule only by asking someone who has been here for years.

Why workarounds fail

Why timers alone are not enough

System timers improve reliability but do not fix dependency isolation.

You still want a uniform secret and logging story across jobs and APIs.

How Inquir fits

Single platform

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

Cron strings are validated when you save the pipeline; the worker tracks nextRunAt per pipeline so edits reschedule cleanly.

Capabilities

Primitives

Cron + worker cadence

Expressions are parsed with cron-parser; firing aligns with the 30s ScheduleWorker poll.

Execution history

Answer “did the job run?” without grep.

Alerts

Hook monitoring to failure rates or duration SLOs.

Steps

How to roll cron jobs onto Inquir pipelines

Codify the handler, test invokes, then attach a schedule trigger with a validated cron expression.

Codify

Move logic from shell to a typed handler.

Test

Invoke manually until outputs match expectations.

Schedule

Create the pipeline trigger (type schedule) and validate the cron string in the API/UI.

Code example

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 };
}

Fit

Choose this when…

When to use

Nightly ETL
Certificate or token rotation
Periodic polling integrations

When not to use

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.