Garmingo Docs
Types

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:

FieldPurposeGuidance
URLTarget endpointPrefer dedicated /health route
MethodHTTP verbUse GET for idempotent checks
TimeoutAbort after X ms3–5s typical; keep below user-facing SLO
Expected Status (if available)Valid status codesInclude 2xx + required 3xx if using redirects
KeywordAssert response contains phraseUse unique stable token
HeadersAuth / Accept customizationAvoid secrets in URL query

Optional Settings

SettingUse CaseNotes
HeadersCustom auth or content negotiationAvoid secrets in URL
BodyPayload for POST/PUTKeep small for faster checks
AuthenticationBasic / Bearer tokensRotate tokens regularly
Keyword MatchingEnsure body contains phraseUse a unique stable keyword
Follow RedirectsTrack 30x chainLimit 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

TechniqueBenefit
Separate /health with limited logicFast & stable response
Omit heavy DB queriesLower 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