Some links in this article are affiliate links. We earn a commission at no extra cost to you when you purchase through them. Full disclosure.
Monitor the public application boundary without exposing a private model server or turning every probe into a paid generation request. This tutorial is research-based guidance, not a tested ten-minute production setup.
Disclosure: We may earn a commission if you sign up through links on this page.
evaluate UptimeRobot for public AI-application health checks. Direct product evidence is the current pricing and feature matrix, checked October 1, 2026.
Current plans
The current catalog uses Free, Solo, Team, Scale and Enterprise—not a universal “Pro $7” plan. The published interval distinction is five minutes for Free, 60 seconds for Solo, 30 seconds for Team and 15 seconds for Scale. Free lists 50 monitors; paid prices depend on monitor tier, billing term and offer.
The page’s summary and feature matrix are not perfectly consistent about every free entitlement. Confirm the selected account’s API, SSL, integration and alert capabilities instead of assuming they all belong to Free. Record the actual checkout price; no contradictory dynamic amount is promoted as a fixed global rate.
1. Expose only a bounded application health route
Use HTTPS on an application endpoint such as https://your-app.example/health. Return a small readiness result, not stack traces, provider credentials, model names or internal resource details.
An illustrative response is:
{"status":"ok"}Compute readiness from bounded internal checks or a recent internal diagnostic result. Do not execute expensive inference on each internet-facing health request. Rate-limit the route and consider a narrowly scoped monitor credential when health details are not public.
2. Configure a monitor
Create an HTTP monitor for the application-owned health route. Configure expected status and, if the selected plan supports it, a keyword or JSON-field check. Test a controlled healthy and unhealthy response before relying on alerts.
A responding HTTP server does not prove the model is accurate, fast or usable. Keep model-quality tests and authenticated synthetic requests separate.
3. Monitor upstream dependencies safely
Do not probe an authenticated /models endpoint without credentials and call its 401 response an outage. A vendor’s public status page is useful context but does not prove your account, region or quota works.
If synthetic calls are required, run a small, budgeted check in controlled infrastructure, keep credentials in the appropriate secret store and report only a sanitized result. Never put bearer keys in public URLs or public status pages.
4. Private systems stay private
Do not expose Ollama port 11434, a database, or a metrics endpoint to the internet merely to let an external monitor reach it. Put checks inside the private network or expose only the authenticated/sanitized application boundary. This guide does not claim a paid UptimeRobot tier includes a private-network agent.
A keyword match cannot calculate “VRAM above 90%”; use an internal metric/alert system for numeric resource thresholds.
5. Alert handling
Start with notifications and a reviewed runbook. Set thresholds that fit probe frequency and known recovery behavior; a five-minute interval does not guarantee a five-minute maximum detection or delivery delay.
Authenticate any webhook, verify its expected payload and prevent replay before acting. Do not accept an unauthenticated request that restarts a production server. The former auto-restart webhook example has been removed.
Public status pages must expose only approved service information. Confirm which contacts, integrations and custom domains the selected plan includes.
A useful monitoring split
| Check | Where it belongs |
|---|---|
| Public application readiness | Bounded external HTTP monitor |
| Authenticated provider call | Controlled synthetic check with secret storage |
| Model quality or token latency | Workload-specific internal test |
| Ollama, database and VRAM | Private operational monitoring |
| Webhook recovery | Authenticated, reviewed automation |
FAQ
Is HTTP enough for a WebSocket app?
It is a basic reachability check, not proof of a WebSocket session. Test the protocol separately if it matters.
How should slow responses be handled?
Measure normal behavior and configure supported timeouts and retry thresholds. Avoid sending expensive generation prompts just to create a response-time graph.
Should I upgrade?
Only for required intervals, features, contacts or scale. Compare the current account matrix, not the retired Pro label.
Related: fallback patterns, latency handling, deployment checklist and LLM alerting.