Account protection
Passwords are hashed, account email addresses are verified with short-lived attempt-limited codes, and changing your password signs out your other sessions.
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.
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
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 ›
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.
- Admin pages require both a platform-admin account and an explicitly allowlisted network address.
Credential handling
Use dedicated, revocable credentials.
Job authentication secrets, custom header values, request bodies, webhook URLs, signing secrets, and bot tokens are encrypted before they are written to the database, using AES-256-GCM. The key is held outside the database and is never included in a database backup, so a stolen copy of the data does not reveal them. Workers decrypt each value only at the moment they send your request.
Authentication secrets, signing secrets, and bot tokens are also write-only. Once saved, they are never displayed again, so nobody can read them back out of a page you have open. You can replace one at any time.
Encryption cannot protect a credential from the service you point it at, and anyone who can sign in to your account can still replace a job's destination. Treat the guidance below as the primary control.
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, errors, URLs, timings, and up to 10 KB of a stored response body. Larger bodies are truncated. 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.
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: