Changelog

Product updates,
without the noise.

Release notes, feature additions, and fixes for CronEngine. Follow what changed, why it matters, and which parts of the scheduler got better.

Feature additions Improvements Release history
Product changelog illustration

Latest

v2.11.0

Current cycle

v2

Focus

Scheduler

Release notes

Every visible product change.

Dates are grouped by release month. Larger platform releases include extra context so the update is easier to scan later.

v2.11.0

latest
September 2026

CronEngine can now watch work it does not run, jobs can follow one another, a failed run can try again on its own, and requests can carry values that change per run.

Added

  • Heartbeat monitoring: watch work CronEngine cannot run for you. A crontab on your own server, a Kubernetes job, a backup script: add one line that pings a URL when it finishes, and we raise the alarm when that ping stops arriving. It catches what an outbound check never can, because if the machine is switched off nothing fails and nothing is reported, and the only signal is the silence. Expect a ping every so often, or on a schedule with the same cron editor a job uses, so work that only runs on weekday mornings stays quiet all weekend instead of alarming every Saturday. Optional start and fail pings give you a duration and catch a run that begins but never ends. Monitors have their own plan allowance (2 on Free through 1,000 on Enterprise) and never touch your scheduled runs. Alerts reach your account email plus any channel your jobs already use.
  • Heartbeats have their own section. The dashboard now has a section switcher: cron jobs and heartbeats each have their own page, their own counts and their own maps. Maps are no longer shared between the two, so organising your monitors cannot disturb how your jobs are filed.
  • One job can now run after another: switch a job's schedule from Repeats to After a job, pick the job it should follow, and say which ending starts it: only after it succeeds, only after it fails, or either way. The follower has no clock of its own. It is armed when the job above it finishes an execution, retries included, and starts on the verdict that execution ended with, which is the one thing a cron expression cannot express. It costs what the job it follows costs, because it runs exactly as often, and changing the schedule at the top of a chain reprices everything below it. Chains stay deliberately small and predictable: one job to follow per job, up to 5 followers each, at most 5 jobs long, and a link that would loop back on itself is refused when you save. Delete a job that others follow and they are paused rather than left waiting on something that no longer exists. The option only appears once your account has a job worth following.
  • One-off requests: a job can now run at a single moment instead of repeating. Switch the schedule from Repeats to Once, pick a date and time, and it fires then and marks itself Completed. Everything else is unchanged: the same request options, retries, notifications and run history, and it sits in your job list showing the moment it will fire. One-off requests have their own monthly allowance (5 on Free through 5,000 on Enterprise), so they never draw on your scheduled runs, and a pending one does not occupy an active-job slot.
  • Automatic retries: a job can retry a failed run by itself, from 1 retry on Starter up to 5 on Enterprise. Retries are off on every job until you turn them on, under Execution behavior in the job form, because only you know whether calling your endpoint twice is safe. Two things to weigh before enabling them: your endpoint receives the same request again seconds later, so work that must not happen twice should either stay at zero retries or deduplicate on the execution id; and a retry does not extend the request timeout, it starts a fresh attempt after the previous one was cut off. The form shows how long a failing run can stay busy at the setting you choose.
  • Only transient failures are repeated: timeouts, refused or reset connections, and statuses that mean come back later (408, 425, 429, 500, 502, 503, 504 and Cloudflare 52x). A 404, a 401, an unresolvable hostname, or a response that failed your own success rules is treated as a final answer. Waits grow between attempts: 15 seconds, 30, 60, then 2 minutes, each slightly randomised.
  • Execution identity headers: every outbound request now carries X-CronEngine-Execution-ID, X-CronEngine-Attempt and X-CronEngine-Scheduled-At. All attempts of one run share the execution id, so an endpoint that must act only once can deduplicate on it. Test request sends them too, so that logic can be tried from the form.
  • Variables in the URL, headers and body: write {{now}}, {{now.date}}, {{now.unix}}, {{job.id}}, {{job.name}}, {{execution.id}}, {{execution.attempt}} or {{execution.scheduled_at}} and CronEngine fills them in as the request goes out. Values are encoded for where they land, so a job name with a space or a quote cannot break a URL or a JSON body, and variables are not accepted in the hostname. Names CronEngine does not recognise are sent through exactly as written, so a template meant for your own system still passes through untouched. The full list is under Variables you can use in the job form and in the documentation.

Removed

  • The Agenda page has been retired. Everything it showed is available where you are already looking: each job's next run is on the dashboard, and the job form previews the next five runs of a schedule while you build it, which is where a mistimed schedule is actually worth catching. Nothing about how your jobs run has changed.

Changed

  • One occurrence is one run, however many attempts it takes. A retried run uses a single scheduled run from your allowance, occupies one slot of history, and counts once toward success rate and consecutive failures. Notifications wait until the run is really over, so a failure that succeeds on its retry never alerts you.
  • Overlap protection now covers the whole retry sequence. With Prevent overlapping runs on, the next occurrence is held back while an earlier one is still retrying, not only while a single request is in flight.
  • Run history and the CSV export show which attempt each row was and how many the run made, alongside the execution id shared by all of them.
  • One place to import from. Pasting a cURL command now happens in the same Import overlay as JSON and crontab, instead of its own separate dialog, and it is available while editing a job rather than only while creating one. A cURL command still fills only the request: your name, schedule and notifications are left as they are.
  • Downgrading a plan lowers any job asking for more retries than the new plan allows, and the change summary email says so.
  • Scheduled runs always leave from 45.9.188.216. When your endpoint publishes an IPv6 address as well as an IPv4 one, CronEngine now still calls it from the IPv4 address on the allowlist page, so a single firewall rule covers scheduled runs, test requests and notification deliveries alike.

v2.10.0

September 2026

Stronger protection for the credentials your jobs carry, and for your account itself.

Added

  • Encrypted job credentials: authentication secrets, custom request headers, request bodies, notification destination URLs, signing secrets, and bot tokens are encrypted before they are stored. The key is held outside the database and is excluded from database backups, so a copy of the data on its own does not reveal them. Each value is decrypted only at the moment your request or notification is sent.
  • Write-only secrets: once saved, an authentication secret, signing secret, or bot token is never displayed again, including to you. Leave the field blank to keep the stored value, or type a new one to replace it.
  • Stronger sign-in protection: repeated failed sign-ins against an account now face a growing delay, which shuts down password guessing spread across many addresses. A device that has signed in before is unaffected, and a successful sign-in clears the delay immediately.
  • Password reset signs you out everywhere: resetting your password now ends every active session and remember-me cookie on the account, so recovering access also locks out anyone else who had it.

Changed

  • Skipped runs are now visible. When overlap protection holds back an occurrence because the previous run is still going, the run history for that job says so and shows how often it has happened. Skipped occurrences are not failures and do not affect your success rate.
  • Run history shows start delay. Each run now records when it was due as well as when it actually started, so you can see how promptly your jobs are picked up.
  • The manual run action is now called Run now everywhere, and testing unsaved form values is Test request. Previously the same two actions appeared under three different names.
  • Exported job files no longer include signing secrets or bot tokens, so an export you store or share cannot carry them. Re-enter those values after importing.
  • The status page now shows when each component last reported and when the page itself was last updated, so you can tell at a glance how current a reading is.

v2.9.0

July 2026

Weekly and monthly account digests make job health easier to review without adding more real-time noise.

Added

  • Email digests: receive a weekly or monthly report covering total runs, successful and failed runs, success rate, average duration, and the jobs with the most failures.
  • Timezone-aware delivery: weekly reports arrive after 08:00 Monday and monthly reports after 08:00 on the first day of the month in the account timezone.
  • Digest preferences: change the cadence or turn summaries off from Account settings. Empty reporting periods are skipped automatically.
  • Cron macros: use @hourly, @daily, @midnight, @weekly, @monthly, @yearly, or @annually in job forms and imports.
  • Overlap protection: jobs now skip a due occurrence when the previous run is still busy, with a per-job toggle enabled by default.
  • Free-plan failure protection: a job is automatically paused after 20 consecutive failed runs, with a dedicated account email and a clear dashboard label.
  • Public security page: a plain-language overview of current account, request, notification, browser, credential-handling, and responsible-reporting practices.
  • Legal agreement history: account settings now show the exact Terms and Privacy Policy versions recorded for the account.
  • Hardened email verification: signup now uses eight-digit, slow-hashed one-time codes with per-code attempt exhaustion and database-backed email/IP throttling.
  • HTTP integration recipes: guides for calling Laravel, WordPress, GitHub Actions, Vercel, and custom endpoints with CronEngine’s existing request options.

Changed

  • Service-owner signup alerts are now sent only after the user successfully verifies their email address.
  • Deleting an account now immediately cancels every active Stripe subscription for that customer. If Stripe cannot confirm cancellation, the account remains active and the user can retry safely.
  • Changing the account timezone now atomically recalculates the next run of every active cron job.
  • Response-storage descriptions now state the 10 KB capture limit and truncation behavior consistently across forms, documentation, and product pages.
  • The Privacy Policy now explicitly discloses optional response-body storage, its 10 KB limit, retention, and the possibility that endpoint responses contain personal or sensitive information.
  • Payment-failure and payment-pause emails now open the Billing settings panel directly.
  • Billing copy and operator documentation now explain that Facturalia handles automatic Peppol or email/PDF delivery outside CronEngine, while preserving the internal manual-invoice action alert.
  • Every admin route now has a fail-closed IP allowlist in addition to platform-admin authentication and CSRF protection.
  • Administrators can inspect bounded, read-only previews of current operational files under Storage without exposing archived logs, backups, symlinks, binaries, or arbitrary server paths.
  • Signup now validates legal agreement server-side and records the exact immutable Terms version agreed to and Privacy Policy version acknowledged. Material Terms updates require a fresh explicit agreement before product access continues.
  • Email verification is now bound to the signup email, resend cooldowns cannot be bypassed by clearing browser state, and both verification and resend submissions require CSRF protection.
  • Stripe webhooks are now processed transactionally with durable event-ID deduplication, stale-event ordering guards, and terminal subscription deletion protection. Billing emails are dispatched only after the state change commits.

v2.8.0

July 2026

Smarter per-job notifications and stronger outbound request protection.

Added

  • Verified notification addresses: custom notification emails now receive a one-time verification link before any job alert can be delivered to them.
  • Health-change alerts: notify when a healthy job starts failing and once more when it recovers.
  • Consecutive-failure thresholds: wait for a configurable number of failed runs before opening an incident and sending an alert.
  • Durable notification delivery: email, generic webhook, Slack, Discord, and Telegram events are stored in a retryable outbox, so temporary provider failures are retried instead of silently lost.
  • Signed webhook contract: generic webhooks receive a stable versioned event with job and run details, a history link, an idempotency ID, and optional HMAC verification.
  • Webhook documentation: payload fields, signatures, retries, security behavior, and provider setup are now documented at /docs/webhooks.

Changed

  • Scheduled-run allowances are now 3,000 / 10,000 / 30,000 / 90,000 / 300,000 across Free through Enterprise, right-sized around cron automation workloads.
  • Enterprise job forms no longer suggest upgrading for a longer timeout or higher run allowance when the account is already on the highest plan.
  • New jobs default to an email on each failed run. Every-run notifications remain available on Starter and above.
  • Notification destinations are stored as separate per-job channel records, with existing jobs converted to email automatically.
  • Scheduled and manual requests now reject CronEngine hostnames, private and reserved networks, and deployment-specific blocked public IPs.
  • Notification delivery re-checks DNS before every attempt, pins the vetted address, requires HTTPS, disables redirects, bounds responses, and limits provider retries.
  • Daily notification caps now apply separately to each channel type, and the dashboard shows the busiest channel for the current UTC day.

v2.7.0

July 2026

Account security tools. See and control where you are signed in, get alerted to sign-ins from new locations, and move jobs in and out as JSON or a crontab.

Added

  • Active sessions: a Security page under Settings lists every device signed in to your account with its IP and last-seen time. Sign out any single device, or sign out everywhere but the one you are on.
  • New sign-in alerts: an email whenever your account is accessed from an IP address it has not used before, showing the device, IP and time, so you can spot access you did not expect.
  • Job import and export: fill the create or edit form straight from a JSON export or a pasted crontab, or export a job as JSON, from an overlay on the form.

Changed

  • Settings is reorganized into a left-hand menu (Account, Billing, Security, Danger zone) instead of one long page.
  • The status page moved to its own subdomain at status.cronengine.com.

v2.6.0

major
June 2026

Plan limits are simpler. The Active Time Budget measured in seconds is replaced by a straightforward monthly run allowance, and request timeouts now come from your plan instead of being set per job.

Changed

  • Scheduled runs replace the Active Time Budget: each plan now covers a number of runs per 30-day month instead of a budget in seconds. Every tier gained a substantially larger allowance in the process.
  • Request timeout is now a plan setting: 20s on Free, 60s Starter, 150s Pro, 300s Business, 600s Enterprise. It applies to every job automatically and is no longer chosen per job.
  • Stated active job limits: Free, Starter and Pro allow 5 / 25 / 50 active jobs. Business and Enterprise stay unlimited and are bounded by their run allowance instead.
  • Downgrades now email you a summary of exactly what changed, including the new timeout and any jobs that were paused.

Added

  • The job form shows what a schedule will cost in runs per month before you save it, along with how much of your allowance is left.
  • The dashboard has an active job meter alongside the run allowance meter.
  • Jobs paused by a plan limit are resumed automatically when you upgrade again.

Fixed

  • Run estimates are now exact for schedules using the last day of the month, day 31, and specific-month restrictions.
  • Resuming a job after a downgrade or a recovered payment no longer leaves it scheduled in the past, which could make several jobs fire at once.

v2.5.0

May 2026

A public status page so anyone can check whether the platform is running, without signing in.

Added

  • Status page: live uptime and system health, with 90 days of history and a per-day breakdown. It samples every 5 minutes and counts a missing sample as downtime, so a dead server cannot report itself healthy.

v2.4.0

April 2026

Clearer job failures, and stronger protection for your data.

Added

  • Plain-language run failures: the run history now explains why a job failed (request timeout, DNS lookup, connection refused, HTTP status) instead of showing a raw error string.

Improved

  • Nightly off-site database backups, with sensitive tables excluded from the dump.

v2.3.0

March 2026

Test a job on demand, and a refreshed look across the whole site.

Added

  • Test request: fire any job immediately from the create or edit form and see the live response and timing, without waiting for its schedule.

Changed

  • Redesigned home, pricing, FAQ, sign-in and job create/edit pages, plus friendlier empty states.

v2.2.0

February 2026

Live payments, automatic invoices, and dedicated pages for people comparing cron services.

Added

  • Live Stripe billing: subscriptions and payments run against Stripe live mode.
  • Automatic invoicing: Facturalia creates invoices from successful payments and delivers them through Peppol where applicable or by email/PDF otherwise.
  • Comparison and landing pages: CronEngine versus EasyCron and cron-job.org, a WordPress cron replacement, and a webhook scheduler page.

v2.1.0

December 2025

Tools to manage jobs at scale: folders, tags, bulk actions and an agenda.

Added

  • Job maps: organize jobs into folders and subfolders, such as production, staging, or one per client.
  • Tags: color-coded labels to group and find jobs across maps.
  • Bulk actions: pause or delete many jobs at once.
  • Agenda: a timeline of every upcoming run across all your jobs.

v2.0.0

major
November 2025

Complete platform rewrite. CronEngine v2 is rebuilt from the ground up on PHP, Go and MySQL, with a new dispatcher architecture, full Stripe billing, and a redesigned dashboard.

New

  • Dashboard: an overview of all jobs with active and paused counts and per-map grouping.
  • Visual schedule builder: pick intervals without writing cron syntax, with raw cron expressions still supported.
  • Run history: every execution logged with HTTP status and duration, plus up to 10 KB of stored response content and per-job charts to spot slowdowns.
  • Next-run preview: see upcoming execution times before activating a job.
  • Email notifications: alerts on failure or on every run, configured per job.
  • Stripe billing: subscriptions, plan switching, the billing portal, and invoice history across five plans.
  • Go dispatcher: a dedicated background service that fires jobs on schedule and records every result.

Stay current

Want to try the latest release?

Create a free account or head back to your dashboard to see the newest CronEngine changes in context.