Uptime monitoring for SaaS on Render
Render works well for web services, background workers, and managed Postgres: push from Git, get HTTPS, read logs in one place. That dashboard tells you whether your deploy succeeded — it does not tell you whether a customer in another country can reach the API right now, and it does not give them a stable status link when something breaks.
StillOnline probes your production health URL from the public internet, builds a hosted status page you can drop into docs or onboarding, and pings you on email, Telegram (official StillOnline bot), or Slack when checks fail — before support tickets pile up. The steps below assume you already ship on Render; for generic health setup see health check quickstart.
Quick answer
StillOnline runs scheduled HTTP GET checks against your Render app’s /health or /api/health from outside Render’s network, publishes a status page at stillonline.tech/en/s/{id}, and sends owner alerts when checks fail or recover. Free includes one project, one URL, and a five-minute interval; Pro adds more checks, private pages, and REST API plus MCP. You do not install anything on Render — only register a public HTTPS URL.
Why Render teams add external monitoring
Render’s own UI is built for operators: deploy history, metrics, log streams. Customers and integrators live elsewhere — they need a public status page and proof that their hostname answers, not just that the latest build went green inside your account.
External monitoring closes that gap. StillOnline hits the same canonical HTTPS URL you put in API docs, from probe nodes that are not on Render’s network, and surfaces downtime on a page you can share without giving buyers access to your Render dashboard.
| Render shows | StillOnline adds |
|---|---|
| Deploy status, logs | Customer-facing status page link |
| Internal metrics | Probe from outside Render’s network |
| — | Telegram/Slack alerts before your inbox fills with tickets |
Step 1 — Add a health route on Render
Before StillOnline can help, your web service needs a small, fast endpoint the internet can call without a session cookie. Most teams expose GET /health or GET /api/health returning 200 when the process can serve traffic, with no authentication on that path only.
Keep the handler lightweight — under two seconds — so cold starts and brief deploy outages do not false-positive more than you intend. After each deploy, verify from your laptop (not over SSH into the container):
curl -sS -o /dev/null -w "%{http_code}\n" https://your-service.onrender.com/health
For deeper design choices (liveness vs readiness, DB pings), see health endpoint design. First-time StillOnline setup: health check quickstart.
Typical Render mistakes
Free-tier services that spin down when idle can fail an external probe during cold start even when the app is “fine” once warm. Heavy database checks on every health hit can flip red during migrations. If you use a custom domain, monitor the same HTTPS hostname customers type in the browser, not an internal hostname.
| Problem | Solution |
|---|---|
| Service spins down on free tier | Cold start may fail the check — upgrade instance or accept occasional degraded status |
| Health checks DB on every request | Noisy during migrations — use lightweight liveness without a DB ping |
| Custom domain | Monitor the canonical HTTPS URL customers use |
Step 2 — Register in StillOnline
Once curl returns 200 on production, register that exact URL in StillOnline so probes and your status page stay tied to what integrators actually call.
- Sign in (Google or GitHub).
- New project → name it after your product.
- HTTP check → full Render URL, GET, expect 200, five-minute interval on Free.
- Copy status page
https://stillonline.tech/en/s/{project-id}for developer docs, onboarding, and incident emails — not the site footer (public status page guide).
StillOnline does not deploy to Render and does not read Render logs; it only HTTP-gets the URL you paste.
Step 3 — Owner alerts (Telegram bot)
Render will not DM you when the API is down. Link your Telegram account to the official StillOnline bot so downtime reaches your phone while you fix the service.
- Settings → Connect Telegram → open the StillOnline bot → Start.
- Enable Telegram alerts — full walkthrough in Telegram guide.
- Free: pick one owner channel (email, Telegram, or Slack). Pro / Ultimate: enable email, Telegram, and Slack together in settings (pricing).
Compare hosting guides
The same pattern — public health URL, StillOnline check, status link — works on other PaaS hosts. Pick the guide that matches where you also deploy client work:
Related guides
FAQ
Does StillOnline deploy to Render?
No. StillOnline only runs scheduled HTTP GET probes from the public internet against URLs you paste in the dashboard. Your Render build and deploy flow stays unchanged — start with the health check quickstart.
Which Render URL should I register in StillOnline?
Use the production web service hostname customers hit, plus /health or /api/health. Skip preview deploy URLs and hostnames that are not reachable from outside Render’s network.
Can StillOnline monitor Render Postgres as a separate check?
StillOnline checks HTTP URLs, not database sockets. Add a Postgres ping inside your app health handler if DB outages should mark the service down — see health endpoint design.
How do StillOnline owner alerts work when Render is down?
Turn on owner notifications in settings: email, Telegram (official StillOnline bot), or Slack Incoming Webhook. Free includes one channel; Pro / Ultimate enables all three — Telegram guide · email alerts.
Is a Render-specific StillOnline integration required?
No. Any public HTTPS URL that returns 200 on GET works, including *.onrender.com and your custom domain — then share the hosted status page from the project dashboard.