Cal.com is an open-source scheduling platform — a self-hosted alternative to Calendly — that lets individuals and teams create booking pages, manage availability, integrate with Google Calendar and Outlook, and automate scheduling workflows through webhooks and integrations. Revenue-generating teams use Cal.com to book sales demos, customer success calls, support appointments, and job interviews. When Cal.com goes down, booking pages return errors to prospects and customers mid-booking flow, scheduled reminders are not sent, and calendar integrations break — every meeting that should have been booked during the outage is a lost opportunity. Booking page downtime is directly visible to external users who have no other contact path, making it one of the highest-urgency failure modes for teams that depend on inbound scheduling. Vigilmon gives you external visibility into Cal.com's health endpoint, web app dashboard, booking page availability, and SSL certificate so failures are caught within 60 seconds.
What You'll Build
- A monitor on Cal.com's
/api/healthendpoint - An HTTP monitor for the Cal.com web app dashboard
- An HTTP monitor for a booking page to confirm end-user availability
- SSL certificate monitoring for your Cal.com domain
- An alerting setup tuned for revenue-impact scheduling downtime
Prerequisites
- A running Cal.com instance with a public or network-reachable domain
- HTTPS configured (e.g.,
https://cal.example.com) - At least one user and booking page configured (e.g.,
https://cal.example.com/username) - A free account at vigilmon.online
Step 1: Verify Cal.com's Health Endpoint
Cal.com exposes a health check endpoint at /api/health that confirms the application server and its core dependencies are operational:
curl -i https://cal.example.com/api/health
A healthy instance returns HTTP 200 with a JSON body indicating the system status. The health endpoint checks that the Next.js application server is running, the PostgreSQL database is reachable, and core application services are functional. A non-200 response or a timeout indicates the application server has crashed, the database is unreachable, or a required environment variable is missing.
PostgreSQL dependency: Cal.com stores all user profiles, calendar integrations, availability rules, booking records, event types, webhook configurations, and scheduling preferences in PostgreSQL. A database failure makes Cal.com entirely non-functional — no booking pages load, no availability is calculated, no calendar integrations sync, and no existing bookings can be viewed or modified. The
/api/healthendpoint performs a database connectivity check and is your primary indicator of platform health.
Step 2: Create a Vigilmon HTTP Monitor for the Health Endpoint
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://cal.example.com/api/health. - Check interval: 60 seconds.
- Response timeout: 15 seconds.
- Expected status:
200. - Label:
Cal.com Health. - Click Save.
This monitor catches:
- Cal.com Next.js application server crashes or OOM kills
- PostgreSQL connectivity failures — the database stores all booking data, availability rules, and calendar integrations; a database outage makes scheduling entirely non-functional
- Redis failures (if configured for session management or caching) that degrade authentication and performance
- Container restart loops triggered by misconfigured environment variables (
DATABASE_URL,NEXTAUTH_SECRET,NEXTAUTH_URL,CALENDSO_ENCRYPTION_KEY) - Failed database migrations after a Cal.com version upgrade that prevent the server from starting
Step 3: Monitor the Cal.com Web App Dashboard
The Cal.com dashboard is the primary interface used by team members to manage their availability, configure event types, view bookings, and manage calendar integrations. Monitor it independently from the API health check to catch Next.js rendering failures and reverse proxy problems:
- Add Monitor → HTTP.
- URL:
https://cal.example.com. - Check interval: 60 seconds.
- Expected status:
200. - Keyword:
Cal.com. - Label:
Cal.com Dashboard. - Click Save.
This monitor catches nginx or reverse proxy failures, Next.js build failures that prevent the app from serving pages, and static asset serving errors that result in a broken UI — even when the health endpoint is responding. A broken dashboard means team members cannot update their availability, add event types, or manage their integrations, compounding the impact of any partial failure.
Step 4: Monitor a Booking Page
Booking pages are the external-facing component of Cal.com — they are what prospects, customers, and candidates see when they click a scheduling link. A booking page failure is immediately visible to external users and directly results in lost meetings and revenue. Monitor at least one representative booking page to confirm end-user availability:
curl -i https://cal.example.com/username
# Expected: HTTP 200 with booking page HTML
Replace username with an actual Cal.com username configured on your instance (e.g., sales, support, or the team's primary booking user).
- Add Monitor → HTTP.
- URL:
https://cal.example.com/username. - Check interval: 60 seconds.
- Expected status:
200. - Keyword:
Book. - Label:
Cal.com Booking Page. - Click Save.
This monitor tests the full path that external users experience: Next.js server-side rendering for the booking page, database lookup of the user's availability and event types, and calendar integration queries to check real-time availability. A failure here means bookings are being lost right now.
Revenue impact of booking page downtime: Unlike internal tool outages that affect only your team, a Cal.com booking page failure is externally visible. A prospect who clicks your booking link and sees an error does not wait — they move on to a competitor or give up. There is no automatic recovery path for missed booking opportunities. For sales and scheduling-heavy teams, Cal.com booking page availability is as critical as payment processing uptime. Treat it with the same alerting urgency.
Step 5: Monitor SSL Certificates
An expired SSL certificate on your Cal.com instance has direct revenue consequences:
- All booking pages return TLS errors to external visitors who have no other way to book
- Calendar integration webhooks from Google Calendar, Outlook, and other providers fail with TLS errors, breaking real-time availability sync
- Any webhook integrations (Zapier, Make, custom endpoints) that Cal.com fires on booking events fail
- The admin dashboard becomes inaccessible to team members managing their schedules
- Add Monitor → SSL Certificate.
- Domain:
cal.example.com. - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Step 6: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action |
|---|---|---|
| /api/health | Non-200 response | Check Cal.com container; inspect PostgreSQL connectivity; review Next.js server logs |
| Dashboard | Non-200 or keyword missing | Check nginx/reverse proxy; verify Next.js build is current; inspect container logs |
| Booking Page | Non-200 or keyword missing | Check Next.js SSR; verify database user/event type query; review calendar integration config |
| SSL certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal is functioning |
Alert after: 1 failure for the Booking Page monitor — external users are experiencing the failure right now and bookings are being lost. Use 2 consecutive failures for the health and dashboard monitors to avoid alerts from transient restarts.
Escalation for revenue-critical scheduling: Route Booking Page alerts immediately to whoever owns the sales or scheduling workflow — not just the infrastructure team. A booking page failure at 9 AM on a Monday may mean an entire day of inbound demos fail to book. The faster the business team knows, the faster they can activate an alternative (direct email, manual calendar sharing) while the technical issue is being resolved.
Common Cal.com Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor |
|---|---|
| Cal.com Next.js server crash | Health endpoint unreachable; alert within 60 s |
| PostgreSQL down | Health endpoint fails; all booking pages return errors |
| Database disk full | Bookings cannot be written; new bookings fail silently |
| Redis cache failure | Session issues; performance degradation visible in page load |
| Calendar integration token expired | Availability data stale; may not surface as a health failure |
| Next.js build failure after upgrade | Dashboard keyword check fails; blank page served |
| Reverse proxy misconfiguration | Booking page and dashboard monitors fire; health endpoint may still pass |
| Missing environment variable after container restart | Health endpoint returns 500; NEXTAUTH_SECRET or DATABASE_URL missing |
| SSL certificate expires | SSL monitor alerts at 30 days; all external booking blocked |
| DNS misconfiguration | All monitors fire simultaneously |
| Webhook delivery failure | Integrations silently stop; bookings recorded but no downstream actions |
| Calendar OAuth tokens revoked | Availability sync broken; old availability rules shown to bookers |
| Container OOM kill under high booking load | Health endpoint intermittently unreachable; flapping alerts |
Scheduling infrastructure is revenue infrastructure — when Cal.com's booking pages go down, meetings are lost in real time with no recovery path. Vigilmon watches Cal.com's health endpoint, web app dashboard, booking page, and SSL certificate so you're alerted within 60 seconds of any failure, before a cascade of missed bookings becomes a revenue reporting problem at end of quarter.
Start monitoring Cal.com in under 5 minutes — register free at vigilmon.online.