Protection built around
every scheduled request.

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.

• Optional two-step sign-in with an authenticator app, plus single-use recovery codes for when the phone is lost.
• 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.

A URL is checked when a job or uptime monitor is saved and again each time 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.
• Uptime checks are plain GET or HEAD requests with a 10 second limit. They never carry your headers, a body or credentials.

Each heartbeat gets its own address with a 128-bit random token in it. That address is the only key, so treat it like a password and keep it out of public code.

• An unknown address gets the same answer as a paused one, so nobody can test which addresses exist.
• Pings repeated within a few seconds are answered but not recorded, so a script stuck in a loop cannot flood your history.
• A ping sets no cookies and starts no session.
• Each ping stores its time, the sender’s IP address and user agent, and history is capped per heartbeat by your plan.

A status page shows the names you give your monitors, how they are doing, their uptime figures and the updates you write. Nothing appears on it until you add it.

• The addresses you watch are never shown, only the name you chose for each monitor.
• Visitors get no cookies and no session, and the page does not track them.
• An unlisted page still works for anyone with the link, but asks search engines not to list it.
• Logos and icons must be real PNG, JPEG, WebP or GIF images, checked by their content. SVG is refused, files are capped at 512 KB, stored under random names and served so a browser cannot treat them as anything else.
• A custom domain only gets a certificate once we have confirmed that it points to CronEngine.

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.

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.