FAQ | CronFlow Docs
Reliable background jobs, simplified.
Core Functionality & Scheduling
Answers to the most common technical questions about rate limits, timezone handling, and how CronFlow compares to traditional cron implementations.
How does CronFlow differ from traditional system cron?
Traditional cron relies on a single OS scheduler (like Vixie or systemd), which struggles with distributed workloads and lacks built-in retry logic. CronFlow uses a centralized, API-driven scheduler backed by Redis Streams and PostgreSQL. It guarantees exactly-once execution across your fleet, provides native dead-letter queues, and exposes real-time run histories via our REST API and dashboard. You get idempotency keys and automatic backoff without writing custom wrappers.
What timezone handling does CronFlow support?
CronFlow stores all job definitions in UTC internally, but accepts timezone-aware expressions using the IANA database (e.g., `America/New_York`, `Asia/Kolkata`). When you schedule `0 9 * * 1-5` in `Europe/London`, the scheduler automatically calculates the UTC offset, including DST transitions. You can also use `@reboot`-style triggers that respect the target container's local `/etc/localtime` if you enable the `host-timezone` flag in your `cronflow.yaml`.
Are there rate limits on job execution or API calls?
Yes. The Standard tier allows up to 10,000 job triggers per hour and 1,200 API requests per minute. The Enterprise tier scales to 100,000 triggers/hour with dedicated throughput. If you exceed your limit, CronFlow returns a `429 Too Many Requests` response and queues excess jobs in a safe buffer rather than dropping them. You can monitor your quota via the `/v1/usage` endpoint or set up webhook alerts using our `cronflow.quota.warn` event.
Scaling & Observability
Guidance on handling high-volume workloads, debugging failed runs, and integrating with your existing monitoring stack.
How do I handle job failures and retries?
CronFlow implements exponential backoff with jitter by default. You can configure `max_retries`, `retry_delay`, and `backoff_multiplier` per job definition. Failed runs are automatically routed to a Dead Letter Queue (DLQ) after exhausting retries. You can inspect DLQ items via the dashboard or programmatically replay them using `POST /v1/jobs/{id}/replay`. All failure payloads include the full stdout/stderr logs and HTTP status codes if your job is an HTTP webhook.
Can I run CronFlow in air-gapped or private cloud environments?
Absolutely. CronFlow offers a self-hosted Docker Compose stack and a Kubernetes Helm chart. The self-hosted version includes the scheduler, worker pool, Redis, and PostgreSQL. You'll receive a local license key that bypasses cloud API calls entirely. We recommend provisioning at least 4 vCPUs and 8GB RAM for production workloads exceeding 500 concurrent executions.
How does CronFlow integrate with Prometheus and Grafana?
Every CronFlow instance exposes a `/metrics` endpoint compatible with Prometheus scraping. We publish metrics like `cronflow_jobs_total`, `cronflow_job_duration_seconds`, `cronflow_dlq_size`, and `cronflow_worker_queue_depth`. Our official Grafana dashboard (Template ID: 18742) provides out-of-the-box visualizations for throughput, latency percentiles, and failure rates. Just add the CronFlow endpoint as a Prometheus target and import the JSON.
Still need help? Our engineering team monitors the community Slack and responds to support tickets within 4 business hours.