Questions,
answered clearly.

CronEngine runs your scheduled HTTP requests, watches the work you run yourself, and gives you a status page for your customers. Cron jobs call any URL on a schedule you set, heartbeats tell you when a script on your own server stops checking in, and uptime monitors tell you when a site stops answering. All in one account.

A task that runs automatically on a schedule. In CronEngine a cron job sends an HTTP request to a URL such as https://example.com/run-task or a webhook, at the times you choose.

Yes. CronEngine runs from its own servers. Your browser and computer do not need to be on. The only thing that has to answer is the endpoint you are calling.

It depends on your plan’s monthly run allowance: as often as every 15 minutes on Free, every 5 on Starter and every 2 on Pro. Business and Enterprise can run jobs every minute. Use the visual schedule builder, a shortcut such as @daily, or a raw cron expression.

@hourly, @daily, @midnight, @weekly, @monthly, @yearly and @annually. They run in your account timezone. @reboot is not supported.

Yes. The job form shows the upcoming run times for your schedule as you build it, in your own timezone, so a mistake shows up before the job goes live.

Yes. Switch the schedule from Repeats to Once and pick a date and time. It has the same request options, retries, alerts and history as any job, fires at that moment, and then shows as Completed. One-off requests have their own monthly allowance, from 5 on Free up to 400 on Enterprise, so they never eat into your scheduled runs. To send it again, duplicate the job and pick a new moment.

Yes, from the Starter plan. Switch the schedule to After a job, pick the job to follow, and choose when it starts: only after success, only after failure, or either way. It has no clock of its own and waits until the job above it has finished, retries included.

It costs the same as the job it follows, because it runs as often. Following an hourly job reserves another hourly job’s worth of runs and uses an active job slot. A follower set to run only after success simply does not run when the job above it fails. Chains stay small: up to five followers per job and at most five jobs deep, and a loop is refused when you save.

Overlap protection is on by default. If a job is still running when its next time comes, that occurrence is skipped, without counting as a failure or sending an alert. You can turn this off under Execution behavior if running twice at once is safe for that endpoint.

Every active job is rescheduled straight away, so its next run follows the same cron expression in the new timezone. Paused jobs are recalculated when you resume them.

A cron job is work we do for you: we call your URL on a schedule. A heartbeat is the other way round: your script calls us when it finishes, and we tell you when that call stops arriving. An uptime monitor checks that a public address still answers. Together they catch the failure that usually goes unnoticed: work that quietly never started.

Yes, with a heartbeat. Add && curl -fsS https://cronengine.com/ping/hb_… to the end of the line in your crontab. If the ping does not arrive in time, you get an alert. This catches what an outside check never can: when a machine is off, nothing fails, so the only signal is the silence. See heartbeat recipes.

If it runs on a pattern, set the heartbeat to expect a ping on a schedule with a cron expression: 0 3 * * 1-5 expects weekday mornings and stays quiet at the weekend. If it only varies in how long it takes, raise the grace time, which is how late a ping may be. If it only runs when someone clicks a button, a heartbeat is the wrong tool, because there is no “late” without an expectation.

Yes, with an uptime monitor. We check the address from our side, as often as every minute on Pro and up. Every outage is recorded with its start, end and length, and the uptime figure is worked out from those records, so it does not drift as old checks are cleared.

The same rule a cron job uses: a set of accepted status codes such as 2xx,3xx, plus an optional check that the page does or does not contain some text. The text check catches a site that answers 200 while showing an error. Only the first 8 KB of the page is searched, and nothing is stored.

Not unless you want it to. A monitor can wait for several failed checks in a row before it calls a site down, and the default is two. Two confirmations on a one-minute interval means you hear about an outage within about two minutes. Set it to one if you would rather know immediately.

A GET or a HEAD, and nothing else: no custom headers, no body, no login. The timeout is a fixed 10 seconds on every plan, and the response is read only far enough to test your rule. An uptime monitor asks whether a page answers; making something happen is what cron jobs are for.

Yes, from the Starter plan. Turn on Certificate expiry on an uptime monitor and pick your countdowns, from 90 days down to 1. You get one email per countdown, and renewing the certificate resets them. You can also name the issuer you expect, and we will tell you if the certificate starts coming from somebody else.

No. Each has its own allowance and neither touches the runs your cron jobs reserve. Heartbeat pings are free. Their alerts do share the daily notification limit with your jobs.

A page you hand to your customers. It shows the monitors you put on it, how each is doing now and how reliable it has been. When something breaks you post a short update, so people read that instead of emailing you.

Anyone with the link. A page set to unlisted still works for everyone with the address but asks search engines not to list it. Only what you add appears, and the addresses you watch are never shown.

Yes. Upload your logo and a browser tab icon, pick an accent colour, a light, dark or automatic theme, the header style and layout, and add a link back to your site. The page can be shown in English, Dutch, French, German or Spanish, with times in your timezone. You see every change in the editor as you make it.

Yes, on Pro and up. Type an address such as status.yourcompany.com in the page settings, add the DNS record shown there, and we take care of the certificate once it points to us. See the setup steps.

Yes. Each item gets its own name and can sit under a heading you choose, separate from what the monitor is called in your account. The same monitor can appear on several pages under a different name on each.

Post an update and pick its stage: investigating, identified, monitoring or resolved. Open updates sit at the top of the page. Planned maintenance can be announced the same way, ahead of time. Everything you wrote stays as a history people can read back.

It only counts time we were actually watching. A monitor added yesterday says so rather than claiming a clean three months, and planned maintenance still counts, so it is not a number you can quietly improve.

Status pages are included from the Starter plan, with 1 page and up to 5 monitors on it. Higher plans allow more pages and more monitors per page. See every plan.

All requests come from 45.9.188.216. If your endpoint sits behind a firewall or allowlist, allow this address so our requests get through.

No, plain HTTP works too. HTTPS is strongly recommended, so your requests and the replies stay private on the way.

Yes. The URL, headers and body can contain variables such as {{now}}, {{now.date}}, {{job.name}} and {{execution.id}}, filled in when the request goes out. Values are encoded for where they land, so a quote in a job name cannot break your JSON. Anything CronEngine does not recognise is sent as written. The full list is in the documentation, and Test request shows the finished request before you save.

The timeout comes from your plan and applies to every job, from 20 seconds on Free up to 600 seconds on Enterprise. A request still running at that point is cancelled and recorded as a failure. Upgrading raises it for all your jobs at once.

Only if you turn it on, per job, from 1 retry on Starter up to 5 on Enterprise. Only failures a second try could fix are repeated: timeouts, dropped connections and answers such as 429, 502 and 503. A 404, a 401 or an answer that failed your success rules is left alone. The wait grows between attempts, roughly 15 seconds, 30, 60, then 2 minutes. All attempts together use one scheduled run, and you are only alerted once the run is really over.

Two things. First, your endpoint gets the same request again, seconds later, so whatever it does it may do twice. If that is not safe, leave retries off, or have your endpoint ignore a repeat: every attempt of one run carries the same X-CronEngine-Execution-ID header. Second, retries do not give a request more time. Each attempt is still cut off at your plan’s timeout. The job form shows the worst case for the number of retries you pick.

Each plan covers a number of scheduled runs per 30-day month, shared across your active jobs. A job costs as many runs as its schedule fires:

every minute = 43,200 runs a month
every 5 minutes = 8,640
every 15 minutes = 2,880
hourly = 720
daily = 30

The cost is reserved when you save the job, so your allowance never runs out halfway through a month. Paused jobs do not count.

5 active cron jobs, 3,000 scheduled runs a month, a 20 second timeout, 2 heartbeats and 1 uptime monitor. That is enough for four hourly jobs, or one job every 15 minutes plus four daily ones.

On the Free plan, a job is paused after 20 failed runs in a row, so an abandoned endpoint stops using up runs and sending alerts. We email you once when it happens. Fix the endpoint and resume the job, and the count starts fresh. Paid plans are never paused by this rule.

Three things. Every job’s timeout drops to the lower plan’s value. Jobs set to retry more often than the lower plan allows are reduced to its limit. And if you have more active jobs or runs than it allows, the extra jobs are paused, starting with the most frequent schedules. Nothing is deleted, we email you a summary, and jobs paused this way are resumed if you upgrade again.

Yes. Pause any job or monitor from the dashboard and resume it any time, with its address, schedule and settings intact.

Its status code and duration, and when response storage is on, up to 10 KB of the reply, marked as truncated when it was longer. Every job has a chart, and you can export the history of any job or monitor as a CSV file.

Email, Slack, Discord, Telegram or your own signed webhook. For a cron job you choose when: every failure, only when it goes down and comes back, after a number of failures in a row, or every run. Heartbeats and uptime monitors alert when they go down and when they recover.

Weekly digests arrive after 08:00 on Monday and cover the previous week. Monthly digests arrive after 08:00 on the 1st and cover the previous month. They use your timezone, skip periods with no runs, and can be changed or turned off in your account settings.

A stable version 1 JSON event with an event id, an event type such as job.failed or uptime.down, the job or monitor it is about, the outcome and a link to its history. Add a signing secret to verify each request, and use the event id to ignore a duplicate. Read the webhook documentation.

Set a maintenance window. Alerts are held, but the outage is still recorded, so a deploy does not page anyone and does not quietly improve your uptime figure. A window only counts if it existed before the outage began, and it can cover cron jobs and monitors together.

Yes. Under Security in your settings you can add an authenticator app, and you get single-use recovery codes in case you lose your phone. Turning it on or off asks for your password.

Yes. When your account is signed in to from an IP address it has not used before, we email you the device, address and time. If it was not you, the email links to your Security page, where you can change your password and sign out every other session.

Yes, from the pricing page or the billing portal. Upgrades take effect straight away. If a lower plan cannot fit what you use now, we show you what would change before you switch.

Use the contact form, or email us at support@cronengine.com. We usually answer within one working day.