Pipeline scheduling with logs, retries, and API integration
Schedule a pipeline with a cron trigger and run functions as its steps: validated expressions, execution history, retries, and the same secrets and observability as your HTTP endpoints. Scheduling belongs to the pipeline; it is not a separate service.
Last updated: 2026-06-28
Answer first
Direct answer
Pipeline scheduling with logs, retries, and API integration. In Inquir, a scheduled pipeline runs serverless functions as steps. HTTP routes can call the same functions. They share workspace secrets, execution history, alert rules, and container isolation. Scheduling is a trigger type on a pipeline—not a separate product.
When it fits
- Teams that want cron jobs and API endpoints in one platform with shared observability
- Jobs that need retries, history, and alerting without a separate scheduler service
Tradeoffs
- Tools like Heroku Scheduler or EasyCron give you a scheduled HTTP call—but you still need the serverless function, the secrets model, and the observability layer separately.
- When the scheduled job calls an internal API, accesses a database, or writes to object storage, the security model for those credentials lives somewhere else—usually a fragile env file.
Workload and what breaks
What a real cron job platform needs
- Expression validation before the first missed run
- Execution history: when did it run, how long, what output
- Retries: automatic re-run on failure without manual intervention
- Shared secrets with HTTP API routes (no parallel env file on a server)
- Alerts: notify when a job fails or takes longer than expected
Most teams start with crontab on a VPS. It works until scale or team size forces the question: "did the job run last night?" and the answer requires SSH access and log trawling.
Trade-offs
Why standalone schedulers miss the full picture
Tools like Heroku Scheduler or EasyCron give you a scheduled HTTP call—but you still need the serverless function, the secrets model, and the observability layer separately.
When the scheduled job calls an internal API, accesses a database, or writes to object storage, the security model for those credentials lives somewhere else—usually a fragile env file.
How Inquir helps
Scheduled pipelines alongside APIs
In Inquir, a scheduled pipeline runs serverless functions as steps. HTTP routes can call the same functions. They share workspace secrets, execution history, alert rules, and container isolation. Scheduling is a trigger type on a pipeline—not a separate product.
The same function that powers a public REST API endpoint can be a step in a scheduled pipeline. One deploy, two entry points, shared observability.
Compare
Cron platform comparison: what you get and what you operate
A reference checklist for evaluating cron platforms—not a feature marketing table.
| Capability | crontab | systemd timer | Heroku Scheduler | Inquir |
|---|---|---|---|---|
| Expression validation | At runtime | At unit install | Fixed intervals only | At save time |
| Run history | Syslog / mail spool | journalctl (host only) | None | Console—30-day retention |
| Retries on failure | None | OnFailure= unit option | None | Per-step policy |
| Shared secrets with API | Separate .env files | Separate service files | Separate config vars | Same workspace secrets |
| Minimum interval | 1 minute | 1 second (OnCalendar) | 10 minutes | 1 minute |
| Infrastructure you operate | VPS + cron daemon | VPS + systemd | Heroku dyno | None |
What you get
Pipeline scheduling capabilities
Validated cron expressions
Expressions validate at save time. Standard 5-field cron (minute, hour, day, month, weekday), 1-minute minimum interval. Errors surface immediately, not on the next missed run.
Execution history
Every cron run creates an execution record: start time, trigger context, step outputs, duration, and exit status—queryable from the console.
Retries with delay
Configure retry count and delay per step. Exponential backoff or fixed delay. Failed runs are retained in execution history for manual inspection and replay.
Parallel job execution
Multiple cron pipelines run concurrently—no single-thread scheduler bottleneck. Add overlap guards per-job when needed.
What to do next
How to schedule a pipeline on Inquir
Implement the job handler
Write a serverless function. Keep logic idempotent—cron jobs can fire twice on rare scheduler restarts.
Add a pipeline schedule
In the visual pipeline editor, connect a cronTrigger node to the function step and enter the cron expression. Save the pipeline to validate its schedule.
Set alert rule
Add a duration SLO alert: notify when the job takes longer than 10 minutes or exits non-zero.
Code example
Certificate expiry checker (cron job)
Runs daily at 08:00 UTC, checks TLS certificate expiry for a list of domains, and sends alert if any expire within 30 days.
import tls from 'node:tls'; import net from 'node:net'; async function checkExpiry(hostname) { return new Promise((resolve, reject) => { const socket = tls.connect({ host: hostname, port: 443 }, () => { const cert = socket.getPeerCertificate(); socket.destroy(); resolve(new Date(cert.valid_to)); }); socket.on('error', reject); }); } export async function handler(event) { const domains = process.env.DOMAINS_TO_MONITOR?.split(',') ?? []; const results = await Promise.all( domains.map(async (d) => ({ domain: d, expiry: await checkExpiry(d) })), ); const expiringSoon = results.filter( (r) => r.expiry.getTime() - Date.now() < 30 * 86_400_000, ); if (expiringSoon.length > 0) await sendAlert(expiringSoon); return { checked: domains.length, expiringSoon: expiringSoon.length }; }
When it fits
When to use scheduled pipelines
When this works
- Teams that want cron jobs and API endpoints in one platform with shared observability
- Jobs that need retries, history, and alerting without a separate scheduler service
When to skip it
- Simple one-off tasks where a VPS crontab works and has never caused a missed-run incident worth investigating
FAQ
FAQ
Can I test the function before the next scheduled run?
Yes—invoke the function directly from the gateway or console. This tests its handler, not the pipeline schedule or the complete workflow.
How do I handle job overlap?
Add a distributed lock or skip-if-running guard in the handler. For idempotent jobs, overlap is safe by design—use a watermark pattern.