Security at CronEngine

Protection built around
every scheduled request.

Cron jobs often carry access tokens and call important systems. We protect accounts, check outbound destinations, and give you clear controls when something looks unfamiliar.

Create an account Report a security concern

This page describes controls currently implemented in CronEngine. It is not a certification or a guarantee that security incidents can never occur.

Request safety check

Applied before connection

Protected

Destination is public

Private and reserved ranges blocked

Address is pinned

Checked destination address used for connection

Request is bounded

Plan timeout limits execution

Run is isolated

Overlap protection enabled by default

Status and incidents View status ›

Account protection

Passwords are hashed, account email addresses are verified, and changing your password signs out your other sessions.

Safe outbound requests

CronEngine blocks local, private, reserved, metadata, and configured service addresses before scheduled requests connect.

Safer notifications

Custom notification emails must be verified, and generic webhooks can be signed so your server can check their origin.

Current controls

Practical protection, explained plainly.

These are active product behaviors, not future roadmap promises.

Sign-in

You stay in control of account access.

CronEngine keeps a list of active sessions with their recent device and IP information. You can end one session or sign out every other session from your account security settings.

  • After the first login, a successful password sign-in from a new IP address sends an email heads-up.
  • Session and remember-me cookies are restricted to secure web connections and are unavailable to page scripts.
  • Password changes keep the current session and end the others.
  • Account activity records help you review important security and account actions.

Job execution

Scheduled requests are checked before they connect.

A URL is checked when a job is configured and again by the dispatcher when it runs. CronEngine resolves the destination, rejects blocked addresses, and connects to an address that passed that check.

  • Localhost, private networks, link-local ranges, cloud metadata addresses, reserved ranges, and CronEngine hosts are blocked.
  • Redirect destinations are checked too, with a limit on redirect chains.
  • Restricted request headers cannot be supplied through custom job headers.
  • Every plan has a request timeout, and overlap protection is enabled by default.

Notification delivery

Alerts have their own delivery safeguards.

Generic notification webhooks use HTTPS destinations and can include a signing secret. Each event also has an ID that receivers can use to ignore a duplicate delivery.

  • Private, reserved, local, CronEngine, and deployment-blocked destinations are rejected.
  • Webhook connections are pinned to an address that was checked immediately before delivery.
  • HTTPS certificate checks remain enabled and notification redirects are not followed.
  • Delivery attempts are bounded by request-size, retry, and daily plan limits.

Web application

Common browser attacks are limited by default.

State-changing forms require a session-specific security token. Browser security rules also limit which scripts and connections a CronEngine page can use.

  • Forms that change account or job data require a security token from the signed-in session.
  • Pages cannot be embedded in another site’s frame.
  • Browsers are told not to guess file types, and outgoing referrer information is limited.
  • Optional analytics and advertising remain blocked until the visitor consents.

Credential handling

Use dedicated, revocable credentials.

CronEngine currently stores job authentication secrets, custom header values, webhook URLs, signing secrets, and bot tokens in the database as entered so workers can use them. These values may also be included in database backups.

Do not reuse your CronEngine password or another important password. Create a separate token or credential for each integration, give it only the access it needs, and rotate or revoke it if you believe it was exposed.

Data and payments

Clear boundaries around your information.

Security also means being direct about what CronEngine handles and where another provider takes over.

Run data

Run history may contain status codes, response bodies, errors, URLs, and timings. Retention depends on the account plan and cleanup rules.

Read the Privacy Policy ›

Payment details

Paid-plan checkout and billing management are hosted by Stripe. CronEngine stores subscription references, but its own forms do not collect full card details.

View billing information ›

Responsible reporting

Found something that may be unsafe?

Email us with a clear description, the affected page or feature, the impact you expect, and safe steps we can use to reproduce it. Please avoid accessing other users’ data, disrupting the service, or including live passwords and tokens in your report.

Email support@cronengine.com Check service status

Helpful report details

  • A short summary of the issue
  • The page, request, or feature involved
  • Safe reproduction steps
  • The likely impact
  • Screenshots with secrets removed

Last reviewed: