Introducing Crontap built-in uptime monitoring

A customer pinged us with one line: "Also it would be brilliant to have a uptime monitor built in aswell for pings etc." It was the kind of feature request that made immediate sense the second we read it: the Crontap dashboard 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 Resend alerts the moment the URL flatlines.

Why we built it

The thing that pushed us over the edge wasn't "more competitors offer this", though most do. It was that the failure mode of missing an uptime check on something Crontap is firing was already worse for users than the cost of running a separate uptime tool: the dashboard you used to set up the 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 we'd been quietly inflicting.

The customer's email made the case. A customer ask carries the weight of "somebody is right now feeling this", which beats a feature roadmap pretty much every time.

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 to up. 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 Resend pipeline 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.

How it works under the hood

Three short architectural notes for the technically curious:

1. Probing: a Supabase Edge Function (probe-monitors) is invoked once per minute by pg_cron via pg_net. On each tick it pulls the monitors whose next_check_at has elapsed, fires HTTP probes in parallel with a 30-second timeout, writes raw rows to monitor_results, UPSERTs the daily rollup, and updates the next-check timestamp.
2. Storage: raw probe rows feed a daily rollup (monitor_results_daily) maintained by the Edge Function, so the bar chart is one fast SELECT per monitor instead of a 90-day scan over raw rows.
3. Alerts: state transitions enqueue rows into monitor_alerts. The existing crontap-notifications Vercel cron (the one that already drains failed-schedule emails to Resend) was extended to also drain monitor alerts, joined with the same global sendToEmails setting you've already configured. No new inbox plumbing.

The whole thing lives entirely on Supabase and the existing Resend setup. No new vendors, no new env vars to manage.

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 monitors 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 via Resend only in v1, on the same notification email 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.

Thanks to the customer who asked. Keep the asks coming.