HTTP/HTTPS Monitoring

HTTP/HTTPS monitoring is Pingara's most powerful feature, providing deep visibility into your web services' availability and performance.

What Gets Monitored

Every HTTP check captures detailed performance breakdown:

• DNS Lookup Time — How long to resolve your hostname to an IP
• TCP Connect Time — Network latency to establish connection
• TLS Handshake Time — SSL/TLS negotiation (HTTPS only)
• Time to First Byte (TTFB) — How long until the server starts responding
• Total Duration — Full request/response cycle
• Response Size — Bytes transferred
• Status Code — HTTP response code (200, 404, 500, etc.)
• SSL Certificate — Days until expiry (HTTPS only)

This granular data helps pinpoint exactly where slowdowns occur.

HTTP Methods

GET (Default)

Standard method for fetching resources.

Use for:

• Web pages
• APIs returning data
• Health check endpoints

Example:

GET https://api.example.com/status

HEAD (Pro Only)

Identical to GET but only fetches headers (no response body).

Use for:

• Large files (you only care about availability)
• Faster checks (saves bandwidth)
• Server availability tests

Example:

HEAD https://cdn.example.com/large-video.mp4

Performance: 10-100x faster than GET for large responses.

POST (Pro Only)

Submits data to the server.

Use for:

• APIs requiring POST requests
• Form submissions
• Webhooks

Example:

POST https://api.example.com/webhook
Content-Type: application/json
{"event": "health_check"}

Note: Custom headers and request body are configurable in Pro.

Expected Status Codes

Define which HTTP status codes indicate success.

Default Configuration

200,201,202,203,204

Accepts all 2xx success codes.

Common Scenarios

Standard web page:

200

RESTful API:

200,201,204

• 200 = OK
• 201 = Created
• 204 = No Content

Redirect endpoints:

301,302

Use only if you're intentionally monitoring redirect behavior.

Any non-error:

200,201,202,203,204,301,302,304

What Happens on Mismatch

If the server returns a code NOT in your list:

1. Check is marked as failed
2. Consecutive failure counter increments
3. After 2 failures, incident is created
4. Alerts fire

Tip: Enable "Follow Redirects" instead of adding 301/302 to expected codes. This monitors the final destination, not the redirect.

Keyword Validation

Verify that response content contains a specific string.

Why Use Keywords?

Detects "silent failures":

• ✅ Server returns 200 OK
• ❌ Page shows error message
• ❌ Database connection failed
• ❌ Wrong version deployed

Configuration

API health check:

Keyword: "status":"healthy"

Web page rendering:

Keyword: Welcome to My Site

Version verification:

Keyword: v2.1.0

How It Works

1. Pingara fetches your URL
2. Receives 200 OK (or other expected code)
3. Searches response body for keyword
4. If missing, marks check as failed

Case Sensitivity

Keywords are case-sensitive:

• ✅ "status":"healthy"
• ❌ "status":"Healthy" (won't match)

Best Practices

Use JSON paths for APIs:

"status":"ok"

Use unique text for pages:

Dashboard - Logged In

(Not just "Welcome" which might appear on error pages)

Test keywords manually:

curl https://your-url.com | grep "your-keyword"

SSL Certificate Monitoring

For HTTPS URLs, Pingara automatically tracks SSL certificate expiry.

Default Warnings

Alerts fire at:

• 30 days before expiry
• 14 days before expiry
• 7 days before expiry

How It Works

Every check:

1. Pingara extracts the SSL certificate
2. Reads the "Valid Until" date
3. Calculates days remaining
4. Triggers alert if threshold crossed

Customizing Thresholds

Add more urgent reminders in monitor settings:

30, 14, 7, 3, 1

Now you'll also be alerted at 3 days and 1 day before expiry.

Milestone-Based Alerting

Pingara sends one alert per threshold:

• Day 30 → First alert
• Day 14 → Second alert
• Day 7 → Final alert

You won't receive repeated alerts at the same threshold.

What Triggers SSL Alerts

• Certificate expiring soon
• Certificate already expired
• Certificate chain invalid
• Self-signed certificate (if not expected)

Redirect Handling

Follow Redirects (Default: Enabled)

When enabled, Pingara:

1. Follows up to 10 redirects (configurable)
2. Validates the final destination
3. Includes redirect hops in total duration

Example flow:

http://example.com 
  → 301 → https://example.com
  → 301 → https://www.example.com
  → 200 OK

Final check validates https://www.example.com.

When to Disable

Monitor the redirect itself:

Expected Codes: 301
Follow Redirects: Off

Detect redirect loops: If your site has broken redirects, disabling follow helps diagnose chains.

Max Redirects

Default: 10

Increase if your app has long redirect chains (rare).

Timeout Configuration

Maximum wait time before marking check as failed.

Default: 30 seconds

Good for most websites.

When to Adjust

Slow backends (increase timeout):

Timeout: 45-60 seconds

Fast APIs (decrease timeout):

Timeout: 10-20 seconds

Why decrease? Faster failure detection. If your API normally responds in <1s, a 30s timeout delays incident creation.

What Counts as Timeout

If total duration exceeds timeout:

• Check marked as failed
• Error type: timeout
• Incident created after 2 consecutive timeouts

Timeout vs Apdex

Timeout — Hard failure threshold (check fails) Apdex — Soft performance threshold (check succeeds but marks as "degraded")

Example:

• Timeout: 30s
• Apdex: 500ms
• Response: 2s → Check succeeds, but Apdex degrades

Custom Headers (Pro Only)

Send custom HTTP headers with your requests.

Use Cases

Authentication:

Authorization: Bearer abc123token

API versioning:

Accept: application/vnd.api+json;version=2

Custom user agent:

User-Agent: Pingara-Monitor/1.0

Format

One header per line:

Header-Name: value
Another-Header: another-value

Security Warning

Never include:

• ❌ Production API keys (use test/monitor-specific keys)
• ❌ User credentials
• ❌ Session tokens

Create dedicated monitoring credentials with minimal permissions.

Request Body (Pro, POST Only)

Send data with POST requests.

JSON Payload

{
  "event": "health_check",
  "timestamp": "2024-01-15T00:00:00Z"
}

Form Data

field1=value1&field2=value2

Set appropriate Content-Type header:

• application/json for JSON
• application/x-www-form-urlencoded for forms

Performance Metrics Explained

DNS Lookup Time

Time to resolve hostname → IP address.

Normal: 10-50ms High: >200ms → DNS server slow or misconfigured

TCP Connect Time

Network latency to establish connection.

Normal: 10-100ms (depends on distance) High: >500ms → Network congestion or server overload

TLS Handshake Time

SSL/TLS negotiation (HTTPS only).

Normal: 50-200ms High: >500ms → Weak cipher suites or CPU bottleneck

Time to First Byte (TTFB)

Time until server starts responding.

Normal: 100-500ms High: >1000ms → Slow backend processing

TTFB includes:

• Server processing time
• Database queries
• API calls
• Caching lookups

Total Duration

Full request/response cycle (sum of all above + transfer time).

Goal: Keep under Apdex threshold for good user experience.

Troubleshooting

"Connection refused"

Server is down or firewall blocking.

"DNS lookup failed"

Hostname doesn't resolve. Check domain configuration.

"SSL certificate invalid"

Expired, self-signed, or wrong hostname.

"Timeout"

Server took too long. Increase timeout or optimize backend.

"Keyword not found"

Response doesn't contain expected text. Check case sensitivity.

"Unexpected status code"

Server returned code not in expected list. Update expected codes or fix server.

Next Steps

• Ping (ICMP) Monitoring — Network-level checks
• Monitor Intervals and Regions — Scheduling and geography
• Apdex Scoring — Performance thresholds
• Setting Up Alerts — Get notified on failures