Crontap is already the place where developers manage HTTPS endpoints on a schedule, and probing a URL on a cadence is the same shape of work as scheduling an HTTPS call. Two halves of the same job, and historically they lived in two tools.
Today we're shipping the second half. Crontap now has built-in uptime monitoring. It lives in the topbar next to Schedules. Paste a URL, pick an interval, get a 90-day green/red bar chart and email alerts the moment the URL flatlines.
Why we built it
The dashboard you use to set up a scheduled call is the same dashboard you'd want to glance at to confirm the URL is responding. Splitting that across two tabs (and two bills, and two notification inboxes) was friction worth removing. Uptime probes also share most of the substrate we already run for schedules: an interval, an HTTPS request, a result row, an alert if something looks wrong. Building it in kept the surface area small and the experience consistent.
What's in the box
The launch shape is intentionally simple:
- Add monitor: paste a URL, pick a name (auto-derived from the URL host if you skip), pick an interval. Done.
- Interval ladder: 1 minute, 5, 10, 15, 30 minutes, hourly, every 6 / 12 / 24 hours. Pro unlocks the full ladder; Free is capped at 1 day.
- Probing: HTTP/HTTPS GET, 30-second timeout. Anything outside HTTP 200–399 (or a network error / timeout) counts as a failed probe.
- State machine: 2 consecutive failed probes flips a monitor to
down(configurable up to 5 per monitor). A single successful probe flips it back toup. No flapping at the boundary. - History: every probe is recorded for 90 days. The list page shows a daily bar chart of your selected window (7 / 30 / 90 days). The detail page shows the last 100 probes in a table with status, duration, and error.
- Alerts: down and recovered emails route to the same notification list you already configured for failed scheduled jobs (Settings → Notifications →
sendToEmails). No second inbox to manage. - Lifecycle: pause / resume, edit name / URL / interval / threshold, delete with confirm. All in the per-monitor detail page.
- Run probe now: every monitor card has a "Run probe now" button. Useful for verifying setup; useful for triggering a re-check before the cron tick fires.
The full feature page is at /uptime.
Pricing
This ships as part of the existing Free and Pro tiers, no separate add-on. Concretely:
- Free: 1 monitor at a 1-day cadence. Enough to feel out the feature on your homepage or your status page; same email alert pipeline as paid.
- Pro: 10 monitors with the full interval ladder down to 1 minute. Bundled with everything Pro already gives you for cron schedules.
If you're already on Pro for scheduling, uptime is included today. Existing schedules and existing notification settings continue to work as-is — nothing changes in the schedules half of the product.
What's not in v1 (but is on the roadmap)
We picked a small surface area on purpose. Things explicitly out of scope today:
- Public status page. The dashboard is private. A public per-monitor status URL (and per-account aggregate page) is on the roadmap.
- Multi-region probes. Single region today. Multi-region matters for some use cases, doesn't for others.
- HEAD method, custom expected status codes, keyword/regex body matching, response-time SLAs. Status-code probing only in v1.
- Slack / Discord / webhook alert channels. Email only in v1, on the same notification list you already configured.
- URLs behind auth (custom request headers). Anonymous GET only in v1.
- SSL certificate expiry tracking, maintenance windows, per-monitor recipient overrides. All planned, none shipped.
If any of these are dealbreakers for your case, the head-to-head with UptimeRobot / Better Stack / Pingdom is honest about which tool wins on which axis.
How to enable it
Nothing to enable. Open the dashboard, click Uptime in the topbar, click Add monitor. The first probe is a "Run probe now" click away.
If you have an existing uptime tool you're considering migrating from, the UptimeRobot alternative post covers what to expect and where the dedicated tools still win in absolute terms. If you're not sure whether you need uptime or a heartbeat (or both), the heartbeat-vs-uptime decision post walks through the four-criteria framework.