Cronitorex combines two models in one product. Your jobs push pings over plain HTTPS, and Cronitorex pulls HTTP and SSL checks from the outside. Nothing to install on your servers, nothing to keep patched.
Failures hide in two places: jobs that stop running and endpoints that stop responding. Push pings cover the first, pull checks cover the second. One dashboard and one alert pipeline for both.
Add one curl line to any cron job, deploy script or worker. Cronitorex records run, complete and fail events and notices when a ping never arrives.
Cronitorex calls your HTTP endpoints and inspects your SSL certificates on a schedule you choose. You see status codes, response times and days to expiry.
Built for developers who want full control over their monitoring stack.
Track start, complete and fail events for any scheduled task. Alert on missed runs or jobs running too long.
Email, webhook, Slack the moment a job fails or an SSL cert is about to expire.
Live event stream, failure analytics, slowest jobs, most active monitors - all in one clean interface.
Response time and status codes for any endpoint. Retries, thresholds, configurable intervals.
Know before your certificates expire. Days-in-advance warnings.
Wrap any job with a single curl. No SDKs, no agents - just standard HTTP.
# mark job complete curl -X POST https://api.cronitorex.com/ping/backup \ -d 'status=complete'
An expired certificate is a full outage with a known date. Cronitorex checks the whole chain, not just the leaf certificate, so a broken intermediate does not surprise you either.
Set your own expiry thresholds and get warned at 30, 14 and 7 days before the date. Wildcard and multi-domain certificates work the same way.
checkout.example.com issuer Let's Encrypt expires in 38 days chain complete · 3 certificates alerts at 30 / 14 / 7 days
A timeout is not a 500, and a DNS hiccup is not an expired certificate. Cronitorex separates transient errors from hard failures, so a network blip does not page you at night.
Transient errors trigger automatic retries with backoff: 60 seconds, then 5 minutes, then 15 minutes. You get one meaningful alert instead of three noisy ones.
Monitors are data, not clicks. Export your whole setup as JSON or YAML, keep it in git and review changes like any other pull request.
The same REST API that receives pings also manages monitors, documented with an OpenAPI spec and Swagger UI. Create or update a monitor from CI in one request.
monitors:
- name: db-backup
type: cron
schedule: "0 2 * * *"
grace: 10m
alerts: [email, telegram]
- name: checkout-ssl
type: ssl
host: checkout.example.com
thresholds: [30, 7] No. Push monitoring is a single HTTP request sent from your own job, and pull checks run from Cronitorex infrastructure. There is nothing to install or update on your servers.
One monitored thing: a cron job, an HTTP endpoint or an SSL certificate. Every plan counts monitors the same way, and you can mix types freely within your limit.
Email, webhook, Telegram and Discord are on every plan, including Free. Slack starts on Pro. PagerDuty is available on Business.
Sign up, get an API key, paste the curl into your cron. That's it.