Replace crontab with scheduled pipelines in Inquir
Cron on a pipeline trigger—the same runs you’d get from HTTP, with history and retries in one place.
Situation
Pain with ad hoc cron
Crontab is seductive until nobody remembers which environment ran the script, which version ran last Tuesday, or why the job stopped mailing output when syslog rotated.
When every job shares one UNIX user and one Python environment, a harmless report script can accidentally step on the dependencies of a finance export.
Sharp edges
Why “just use systemd timers” is not always enough
Timers help with reliability but you still carry packaging, logging conventions, and secret distribution yourself.
Kubernetes CronJob is powerful yet heavy if the rest of your stack does not already live there.
How Inquir fits
How scheduling works in Inquir
When you save a pipeline, the service validates the cron string so typos fail early instead of silently never firing. The scheduler remembers the next run time per pipeline and wakes it when due, so edits to the expression reschedule cleanly.
Because the worker wakes on a fixed interval, think in terms of minute-level jobs for predictable behavior; expressions finer than that may not fire as sharply as a kernel timer would.
Capabilities
Operational wins
Per-job isolation
Containers keep dependency conflicts and file system effects contained.
Shared platform primitives
Use the same secrets and logging model as HTTP handlers.
Composable pipelines
Chain follow-up work when a cron task should fan out.
Steps
How to move a scheduled job onto Inquir pipelines
Implement handler
Write the job logic with explicit inputs from environment variables.
Create schedule trigger
Set pipeline trigger type to schedule and paste a cron expression the API accepts.
Monitor
Confirm durations and failure rates before they become silent data gaps.
Code example
Example: nightly aggregation
Read a watermark from env, query a source system, write results downstream.
export async function handler(event) { // From a scheduled pipeline, event includes pipeline, step, payload, previousOutput, etc. const since = process.env.LAST_SYNC_CURSOR; const batch = await fetchBatch({ since }); await storeSummary(batch); return { processed: batch.length }; }
Fit
When this helps
When to use
- You outgrew one-off crontab and want versioned jobs, isolation, and history next to your HTTP functions.
- You want parity between “API work” and “scheduled work” in one product surface.
When not to use
- You need sub-second global scheduling across many regions (edge-specific designs differ).
FAQ
FAQ
Is this the same as Linux crontab?
No—it's application-level scheduling through Inquir pipelines. The platform decides when your function runs in a container; you configure cron expressions and inspect runs in the product UI.
How do I debug a misfire?
Open the invocation history for the function that backs the pipeline step. You see the payload, logs, and timing for the run that actually executed—far easier than correlating syslog timestamps across SSH sessions.
Can jobs call HTTP routes on the same platform?
Yes. Jobs can invoke gateway endpoints or other internal functions when that keeps boundaries clean.