Why Render.com Health Checks Are Not Enough
Render is a popular platform for deploying web services, background workers, cron jobs, and static sites. It offers a built-in health check system that automatically restarts services when they become unhealthy. Many teams configure this and consider the reliability problem solved. It isn't.
Render's health checks are internal restart logic. They exist to keep your container alive inside Render's infrastructure. They are not external monitoring, and they don't tell you what your users are actually experiencing.
What Render's Health Checks Actually Do
Render's health check feature lets you configure an HTTP endpoint (typically /health or /ping) and an interval. If Render's internal prober hits that endpoint and gets a failure response, it restarts your service.
That's a useful feature for self-healing. But read it carefully: the prober is Render's own infrastructure probing your container over Render's internal network. It is specifically designed to detect "container is crashed" and trigger a restart. Nothing more.
The Critical Gaps
No User-Facing Availability Signal
A service can pass Render's internal health check while being completely unreachable from the public internet. DNS propagation issues, SSL certificate problems, Render's edge network having a regional incident, or a misconfigured custom domain can all produce a situation where Render says "healthy" and your users see a connection timeout.
Vigilmon probes your public URL from external locations — the same path your users take. It doesn't route through Render's internal network. If users can't reach your service, Vigilmon knows within minutes and alerts you. Render's health check has no visibility into this failure mode.
No Alerts When Your Service Is Down From the User Perspective
Render's health check restarts crashed services, but it doesn't send you an alert that the crash happened. You can view health check history in the Render dashboard, but there's no push notification to your Slack, no email, no PagerDuty call. You learn about incidents by checking the dashboard yourself or by users reporting problems.
Vigilmon sends you an immediate alert — via email, Slack, webhook, or SMS — the moment your endpoint returns an unexpected response. You know about the problem before your first support ticket arrives.
No SSL Certificate Expiry Monitoring
Render provides managed SSL certificates for its default .onrender.com domains. For custom domains, you bring your own certificate or rely on Render's Let's Encrypt integration. Certificate renewals can fail when DNS changes interfere with validation, when your custom domain has misconfigured CAA records, or when Let's Encrypt rate limits are hit.
An expired certificate is catastrophic — browsers refuse to load the site and display a security warning that most users won't click through. Render doesn't monitor certificate expiry and won't alert you when your cert is approaching its expiration date. Vigilmon does, with configurable advance warnings starting 14 days before expiry.
No Multi-Location Availability Checks
Render serves traffic from multiple regions, but availability can be asymmetric. A database connection pool exhaustion issue might cause failures only for users in certain regions while others continue to see normal responses. Render's single internal health check probe won't surface this geographic variation.
Vigilmon checks from multiple geographic vantage points simultaneously, flagging regional degradation before it becomes a global incident.
No TCP Port Monitoring
If you're running services beyond HTTP — databases, Redis instances, message brokers, or game servers — Render's HTTP health check has no visibility into them. Vigilmon supports TCP port monitoring, verifying that your non-HTTP services are accepting connections and responding within expected latency thresholds.
No Monitoring for Render Cron Jobs
Render's cron job service runs scheduled tasks inside your deployment. If a cron job silently fails — due to a timeout, an uncaught exception, or a dependency being unavailable — Render logs the failure but sends no alert. There's no built-in mechanism to notify you that a scheduled job stopped running successfully.
Vigilmon's heartbeat monitoring solves this. Your cron job hits a Vigilmon heartbeat URL at the end of each successful run. If the heartbeat goes missing for longer than the configured grace period, Vigilmon pages you.
Why Render Deployments Need Vigilmon Alongside Built-in Health Checks
The right mental model is: Render's health checks keep your container alive; Vigilmon keeps your service available to users. These are complementary, not redundant.
A complete monitoring setup for a Render-deployed application on Vigilmon looks like:
- Primary web service monitor — HTTP check every minute from multiple locations, alert on non-200 or latency above threshold
- API endpoint monitors — separate monitors for critical paths (authentication, payment processing, data API)
- SSL certificate monitor — continuous expiry tracking with 14-day advance warning
- TCP monitors — port checks for any non-HTTP services you expose
- Cron job heartbeats — one heartbeat monitor per scheduled task, matching the job's expected run interval
- Status page — public transparency page for your users and stakeholders
Setting Up Vigilmon for Render Web Services
Add your Render service's public URL as an HTTP monitor in Vigilmon. For custom domains, add a separate SSL monitor for the domain. For cron jobs, create a heartbeat monitor, copy the generated URL, and add a call to that URL at the end of your job script.
Render's restart-on-failure behavior catches containers that crash. Vigilmon catches everything else — the subtle degradations, the external routing failures, the certificate expirations, and the silent job failures that users notice before you do. Both tools belong in a production Render deployment.