Cron job platform with logs, retries, and API integration
A cron job platform that runs scheduled tasks as serverless functions: validated expressions, execution history, retries, and the same API gateway, secrets, and observability as your HTTP endpoints. Not a standalone scheduler—a full backend runtime for jobs and APIs together.
Last updated: 2026-06-28
Answer first
Direct answer
Cron job platform with logs, retries, and API integration. In Inquir, cron jobs and HTTP API endpoints are both pipeline-backed serverless 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
One platform for cron jobs and APIs
In Inquir, cron jobs and HTTP API endpoints are both pipeline-backed serverless 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 triggered by a cron schedule. 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
Cron job platform 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 set up a cron job on Inquir
Implement the job handler
Write a serverless function. Keep logic idempotent—cron jobs can fire twice on rare scheduler restarts.
Create pipeline with schedule trigger
Set trigger type to schedule, enter cron expression. Platform validates and schedules first run.
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 Inquir is the right cron job platform
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 trigger a cron job manually?
Yes—invoke the underlying function directly from the gateway or console to test without waiting for the next scheduled tick.
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.