HTTP
Monitor availability, response codes, latency, and content of HTTP(S) endpoints with configurable assertions.
HTTP monitors test web and API endpoints over HTTP or HTTPS. They measure availability, latency, and optionally validate response status codes and body keywords.
When To Use
- Public or internal REST / GraphQL APIs
- Web landing pages or app health endpoints
- Lightweight synthetic GET to upstream dependencies
When Not To Use
- TCP-only protocols (use TCP monitor)
- Background job freshness (use Heartbeat / Cron)
- Certificate expiry only (use SSL Certificate)
Core Settings
See detailed field reference in Settings but key items:
Field | Purpose | Guidance |
---|---|---|
URL | Target endpoint | Prefer dedicated /health route |
Method | HTTP verb | Use GET for idempotent checks |
Timeout | Abort after X ms | 3–5s typical; keep below user-facing SLO |
Expected Status (if available) | Valid status codes | Include 2xx + required 3xx if using redirects |
Keyword | Assert response contains phrase | Use unique stable token |
Headers | Auth / Accept customization | Avoid secrets in URL query |
Optional Settings
Setting | Use Case | Notes |
---|---|---|
Headers | Custom auth or content negotiation | Avoid secrets in URL |
Body | Payload for POST/PUT | Keep small for faster checks |
Authentication | Basic / Bearer tokens | Rotate tokens regularly |
Keyword Matching | Ensure body contains phrase | Use a unique stable keyword |
Follow Redirects | Track 30x chain | Limit depth to avoid loops |
Success Criteria
- 2xx or acceptable 3xx status code
- (If keyword set) body contains the phrase
- Response under timeout
Latency Tracking
Each check records duration; charts help identify performance regressions. Track p95 to surface tail issues.
Content Assertions
Use minimal keyword checks—overly broad phrases risk false failures when copy changes. For richer validation prefer a dedicated health JSON endpoint returning a static key.
Retries & Noise Control
Retries smooth transient network blips. Start with 2–3. If flapping persists, increase interval slightly or investigate upstream resource saturation.
Securing the Health Endpoint
Technique | Benefit |
---|---|
Separate /health with limited logic | Fast & stable response |
Omit heavy DB queries | Lower false alarms from transient DB slowness |
Return lightweight JSON {"status":"ok"} | Easy machine parse |
Apply minimal auth (token header) | Avoid public exposure if sensitive |
Cloudflare / CDN Considerations
Protective layers may present challenge pages. See Cloudflare Protection for the token header bypass method.
Common Pitfalls
- Using the main landing page (large assets) instead of a slim health path
- Setting timeout longer than user SLO (masks slowness)
- Multiple keywords making content changes brittle
Best Practices Checklist
- Dedicated, fast health route exists
- Latency baseline established (store p95/p99 values)
- Alert integrations attached (chat + durable)
- Maintenance windows cover planned deployments