🌐 HTTP(S) Monitor

The HTTP(S) monitor is the most commonly used monitor type. It makes an HTTP request to a URL and checks whether the response matches your expectations.

---

🎯 What It Does

• Sends an HTTP request (GET, POST, PUT, PATCH, DELETE, HEAD) to your URL
• Checks the response status code (e.g., 200, 301, 404)
• Measures response time and TTFB (Time To First Byte)
• Optionally checks for a keyword in the response body
• Supports authentication (Basic Auth, Bearer Token)
• Supports custom headers and request body
• Can follow or ignore redirects
• Can verify or skip SSL certificate validation
• Captures the resolved IP address

---

⚙️ Configuration

Basic Settings

Setting	Description	Example
Name	A friendly name for this monitor	My Website
Address (URL)	The full URL to check	https://example.com
Check Interval	How often to check	1 minute
Timeout	Max wait time for a response	30 seconds

HTTP Settings

Setting	Description	Default
HTTP Method	GET, POST, PUT, PATCH, DELETE, HEAD	GET
Expected Status Codes	Which status codes mean "up"	200
Authentication	None, Basic Auth, or Bearer Token	None
Custom Headers	Key-value pairs of HTTP headers	Empty
Follow Redirects	Whether to follow 301/302 redirects	✅ Yes
Verify SSL	Whether to verify the SSL certificate	✅ Yes
Max Response Time	Mark as degraded if slower than this (ms)	Not set
Request Body	JSON body for POST/PUT/PATCH requests	Empty

Keyword Search

Setting	Description
Keyword	Text to search for in the response body
Keyword Should Exist	✅ = text must be present, ❌ = text must be absent

---

📖 Usage Examples

Example 1: Basic Website Check

Check if your homepage loads and returns a 200:

Setting	Value
Name	My Website Homepage
URL	https://www.example.com
Method	GET
Expected Status	200
Interval	1 minute

Example 2: API Health Endpoint

Check an API health endpoint that returns JSON:

Setting	Value
Name	API Health Check
URL	https://api.example.com/health
Method	GET
Expected Status	200
Keyword	"status":"ok"
Keyword Should Exist	✅ Yes
Interval	30 seconds

Example 3: Authenticated API

Monitor an API that requires a Bearer token:

Setting	Value
Name	Protected API
URL	https://api.example.com/v1/data
Authentication	Bearer Token
Password / Token	your-api-token-here
Expected Status	200

Example 4: POST Endpoint

Test a webhook or POST endpoint:

Setting	Value
Name	Webhook Test
URL	https://api.example.com/webhook
Method	POST
Custom Headers	Content-Type: application/json
Request Body	{"test": true}
Expected Status	200, 201, 202

Example 5: Redirect Check

Verify that HTTP redirects to HTTPS:

Setting	Value
Name	HTTP to HTTPS Redirect
URL	http://example.com
Follow Redirects	❌ No
Expected Status	301

---

📊 What Gets Recorded

Each check stores:

Metric	Description
Status	Up, Down, or Degraded
Response Time	Total time in milliseconds
Status Code	HTTP status code (200, 404, 500, etc.)
TTFB	Time To First Byte
Resolved IP	The IP address the hostname resolved to
Error Message	Details if the check failed

---

❓ When Is It "Down"?

The monitor is marked Down when ANY of these occur:

1. ❌ Connection timeout (no response within timeout period)
2. ❌ Response status code doesn't match expected codes
3. ❌ DNS resolution failure
4. ❌ SSL certificate error (if Verify SSL is enabled)
5. ❌ Keyword not found (or found when it shouldn't be)

The monitor is marked Degraded when:

1. ⚠️ Response time exceeds the Max Response Time threshold

---

💡 Tips & Best Practices

1. Monitor a dedicated health endpoint (e.g., /health or /api/status) rather than your homepage — it's faster and less likely to be affected by CDN caching.

2. Use keyword checks to verify that the page content is correct, not just that the server responds. A server might return 200 but show an error page.

3. Set reasonable timeouts. If your API normally responds in 200ms, a 30-second timeout is too generous. Set it to 5-10 seconds for faster failure detection.

4. Don't disable SSL verification in production unless you have a specific reason. Self-signed certs in staging? Sure. Production? Use a real certificate.

5. Multiple status codes: If your endpoint might return 200 or 204, list both as expected: 200, 204.