Questions,
answered clearly.

CronEngine is an online cron job scheduler. It sends HTTP requests to any URL you configure on a schedule you define, so you can automate recurring tasks without relying on your own server's cron setup.

A cron job is a task that runs automatically at scheduled intervals. With CronEngine, a cron job works by sending an HTTP request to a URL such as https://example.com/run-task or a webhook endpoint, on the schedule you configure.

How often a job can run depends on the shared monthly allowance: Free covers a single job every 15 minutes, Starter every 5 minutes, and Pro every 2 minutes when no other jobs consume the allowance. Business and Enterprise can reserve every-minute schedules. You can use the visual schedule builder, a shortcut such as @daily, or a raw cron expression.

Yes. When you create a job, switch the schedule from Repeats to Once and pick a date and time in your account timezone. It behaves like any other job - same request options, retries, notifications and run history - but it fires at that single moment and then shows as Completed instead of waiting for a next run. One-off requests have their own monthly allowance (5 on Free, up to 5,000 on Enterprise), so they never eat into your scheduled runs, and a pending one does not use an active-job slot. To send the same request again, duplicate the job and choose a new moment.

Yes. Switch the schedule from Repeats to After a job, pick the job to follow, and choose which ending starts it: only after it succeeds, only after it fails, or either way. The follower has no schedule of its own, so it never fires on a clock. It waits until the job above it has finished an execution, retries included, and starts on the verdict that execution ended with. The option only appears once you have a job worth following, so a first job is never asked about it.

It costs the same as the job it follows, because it runs exactly as often. Following an hourly job reserves another hourly job's worth of monthly runs and uses an active-job slot, and raising the schedule at the top of a chain reprices everything below it. A follower set to run only after success costs nothing extra when the job above it fails, it simply does not run. Chains are kept deliberately small: one parent per job, up to five followers each, at most five jobs long, and a link that would loop back on itself is refused when you save.

Yes, with a heartbeat monitor. It is the mirror image of a cron job: instead of us calling your URL, your script calls a URL we give you, and we raise the alarm when that call stops arriving. Add && curl -fsS https://cronengine.com/ping/… to the end of the line in your own crontab and you are done. This is what catches the case an outbound check never can: if the machine is switched off, nothing fails and nothing is reported, so the only signal is the silence.

You have three options. If it runs on a pattern but not around the clock, set the heartbeat to expect a ping on a schedule and give it a cron expression: 0 3 * * 1-5 expects a ping on weekday mornings and stays quiet at the weekend instead of alarming every Saturday. If it just varies in how long it takes, keep the period and raise the grace time, which is how late a ping may be before we call it down. If it truly runs only when somebody clicks a button, a heartbeat is the wrong tool: there is no "late" without an expectation, and you would be better served by the ping history as a log than by an alarm.

No. An inbound ping costs no outbound request and no worker, so monitors have their own plan allowance (2 on Free, up to 1,000 on Enterprise) and never touch the monthly run reservation your cron jobs share. Alerts do count against the same daily notification cap as your jobs, because that limit exists to protect delivery rather than to ration runs.

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

Yes. CronEngine runs entirely from its own servers. Your browser, local computer, and hosting server do not need to stay online for jobs to fire.

Overlap protection is enabled by default. If the same job is still running when its next scheduled time arrives, CronEngine skips that occurrence without treating it as a failure or sending an alert. You can turn this off under Execution behavior if concurrent runs are safe for that endpoint.

To stop abandoned endpoints from consuming resources and sending endless alerts, a Free job is paused after 20 consecutive failed runs. We send one email to your verified account address when this happens. Review the latest error and resume the job when the endpoint is fixed; resuming starts a fresh failure count. Paid plans are not automatically paused by this rule.

All requests are sent from 45.9.188.216. If your endpoint is protected by a firewall or allowlist, make sure to whitelist this IP address so our requests are not blocked.

No, plain HTTP endpoints also work. That said, HTTPS is strongly recommended to keep your requests and response bodies secure in transit.

Yes. The URL, request headers and request body can contain variables such as {{now}}, {{now.date}}, {{now.unix}}, {{job.name}} and {{execution.id}}, and CronEngine fills them in at the moment the request goes out. Values are encoded for where they land, so a job name containing a space or a quote cannot break your URL or your JSON, and variables are not allowed in the hostname. Anything CronEngine does not recognise is sent through exactly as written, so a template meant for your own system passes straight through. The full list is in the documentation, and Test request shows you the finished request before you save.

Yes. When creating or editing a job, CronEngine shows you a preview of upcoming execution times based on your schedule. This helps you catch mistakes before the job goes live.

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

Every plan covers a number of scheduled runs per 30-day month, shared across all your active jobs. A job's cost is simply how often its schedule fires:

every minute = 43,200 runs/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 unexpectedly in the middle of a month. Paused jobs do not count.

The free plan covers 5 active jobs, 3,000 scheduled runs a month, and a 20 second request timeout. That covers four hourly jobs, or one job every 15 minutes plus four daily jobs - plenty for personal projects and lightweight automation. A single every-minute job costs 43,200 runs a month and requires Business or Enterprise.

No - the timeout comes from your plan and is applied to every job automatically, from 20 seconds on Free up to 600 seconds on Enterprise. If a request is still running when the timeout is reached it gets cancelled and recorded as a failure. Jobs that finish sooner are unaffected. If you need longer, upgrading raises it across all your jobs at once.

Only if you ask it to, per job. Retries are off by default on every job, because CronEngine cannot know whether calling your endpoint a second time would charge a card or send an email twice. Turn them on under Execution behavior, from 1 retry on Starter up to 5 on Enterprise. Only failures a second try could fix are repeated - timeouts, dropped connections, and statuses like 429, 502 and 503 - while a 404, a 401 or a response that failed your success rules is left alone. Waits grow between attempts (15s, 30s, 60s, then 2 minutes). Every attempt belongs to the same run: it uses one scheduled run from your allowance, and you are only notified once the run is really over, so a failure that succeeds on its retry never emails you.

Two things. First, your endpoint will receive the same request again, seconds later. Whatever it does, it may do twice - a payment taken, an email sent, an order created - and we cannot undo that. If repeating the work is not safe, leave retries at zero, 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, so a job that needs longer than that needs a bigger plan, not retries. What does grow is how long a failing run stays busy: attempts and the waits between them add up, and while overlap protection is on, occurrences due inside that window are skipped. The job form shows the worst case for the number of retries you pick.

Three things. Every job's request timeout drops to the lower plan's value, so any job that normally takes longer than that will start failing. Any job set to retry more times than the lower plan allows is reduced to that ceiling. And if you have more active jobs or more scheduled runs than the lower plan allows, the excess is paused automatically - oldest jobs are kept, and the most frequent schedules are paused first. Nothing is ever deleted, and we email you a summary of exactly what changed. If you upgrade again, jobs paused this way are resumed automatically.

Yes. Every run is logged with its HTTP status code and duration. Depending on the job's storage setting, CronEngine also retains up to 10 KB of the response body and marks larger responses as truncated. Per job, alerts can go to email, a generic signed webhook, Slack, Discord, or Telegram for every failure, only when health changes, after a chosen number of consecutive failures, or on every run. You can also receive a weekly or monthly email digest with run totals, success rate, average duration, and the jobs that failed most often.

Weekly digests are sent after 08:00 each Monday and cover the previous Monday through Sunday. Monthly digests are sent after 08:00 on the first day of the month and cover the previous calendar month. CronEngine uses your profile timezone, skips periods with no runs, and lets you switch cadence or turn digests off from Account settings.

Generic webhooks receive a stable version 1 JSON event with an event ID, event type, job name and URL, run ID, outcome, HTTP status, duration, error, timestamps, and a direct history link. Add a signing secret to verify HMAC-SHA256 signatures, and use the event ID to ignore duplicate deliveries. See the webhook documentation for the full contract.

Yes. You can disable any job from the dashboard and re-enable it at any time without losing its URL, schedule, or configuration.

Yes. Whenever your account is signed in to from an IP address it has not used before, we email you a heads-up with the device, IP address and time. If it was you, nothing to do. If not, the email links straight to your Security page where you can change your password and sign out every other session. You can review your active sessions there at any time.

Yes. You can switch plans from the Pricing page at any time. Upgrades take effect immediately. If a downgrade cannot fit your current usage, CronEngine warns you before the change.

Use the contact form, or email us at support@cronengine.com. We typically respond within one business day.