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

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

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 on every plan.

Expected Status Codes

Define which HTTP status codes indicate success.

The list every dashboard-created monitor gets

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

That covers the 2xx codes an HTTP endpoint realistically returns plus the two most common redirect codes. It is a list, not a range, so the rarer 2xx codes (205, 206, 207, 208, 226) are not in it, and neither is 304.

Both the New Monitor form and the Edit Monitor form let you set this directly, under Expected Status Codes. Enter individual three-digit codes, comma-separated, for example 200, 301, 401, and the check passes when the response carries one of them; ranges aren't accepted. The monitor detail page shows the stored list under Configuration → Expected Status Codes. The v1 Developer API returns it, and a write-scoped key (a Pro feature) can set it on POST and PATCH /monitors.

The list above is the dashboard's, not a platform floor: the platform-wide default of 200–399, covering any success or redirect code, applies only to a monitor created without the field at all, which no UI or API path does today. An operator changing it in the Ops Console is what moves it.

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 Checks

Check the response body for a specific string.

Why Use a Keyword Check?

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. Marks the check failed if the text is missing (or, in must NOT contain mode, if it is present)

A HEAD request returns no body, so a keyword check cannot be used with one. Pingara refuses that combination when you save the monitor rather than letting it report down forever.

Pingara reads up to 1 MB of the response. If your keyword sits further down a larger page, the check reports Keyword unverified rather than a failure. We won't claim the keyword is gone when we didn't read that far. Put the keyword near the top of the page, or point the monitor at a smaller endpoint.

Match Modes

A keyword check runs in one of two directions:

• Response must contain - the check fails when the text is missing. Use it to confirm a page actually rendered: an order confirmation, a health string, a version number.
• Response must NOT contain - the check fails when the text appears. Use it to catch a page that serves an error inside a successful response: Internal Server Error, Database connection failed, Account suspended. A status-code check cannot see any of those, because the page returns 200.

Matching is an exact substring test either way. It is not a pattern or a regular expression.

Case Sensitivity

Keywords are case-sensitive by default:

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

Turn Match case off to accept any capitalisation. Leave it on for API responses, where the exact casing is part of the contract.

When the Check Fails

Choose what a failed keyword check does to the monitor:

• Mark degraded (default for new monitors) - you get an alert, but the check still counts as a success for uptime, Apdex and your SLA.
• Mark down - the check counts as a failure, exactly like a timeout or a bad status code.

Degraded is usually right for page content. A keyword check reads the raw HTML, not the rendered page, so it can differ between visitors without anything being broken: an A/B test, a cookie banner, a translated page, a CDN cache variant, or an apostrophe encoded as '. Any of those failing your monitor would take your published uptime figure with it.

Mark down is right for a health endpoint. If /health stops returning "status":"healthy", that genuinely is an outage.

Monitors created before this setting existed are set to Mark down, which is how they have always behaved. Change it on the monitor's edit page.

Best Practices

Use JSON paths for APIs:

"status":"ok"

Use unique text for pages:

Order confirmed

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

Don't use a secret as a keyword. Pick text that is safe to name in an alert: a heading, a status string, a version number. Avoid session tokens, API keys, account numbers, or anything that only appears for a signed-in user. Pingara never puts your keyword into an alert, but a keyword is a monitor setting rather than a credential store. It is visible to everyone in your organisation and is sent to the monitoring probes in order to be matched.

Match text that is stable. Keyword matching is an exact substring test against the raw response body, so it sees the HTML, not the rendered page. Text containing an apostrophe or a quote may be encoded in the source (Tom's rather than Tom's), and text that changes with A/B tests, personalisation, or translation will match in some regions and not others.

Test keywords manually:

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

Domain Expiry Monitoring

A lapsed domain is the outage nothing else here catches early. An expired certificate fails a handshake, so the monitor goes down and you get paged. An expired domain produces no such signal: resolvers keep serving cached answers for a while, and then the website, the email and the API stop at once.

Turn it on for any monitor by choosing warning thresholds from 90, 60, 30, 14, 7 or 1 day. It is off by default, because each enabled monitor means Pingara asks that domain's registry once a day.

It is not tied to monitor type. A ping monitor on db.example.com stops working when example.com lapses exactly as an HTTP one does.

What You Get

A notification, not an incident, just like certificate expiry. Your uptime, Apdex and SLA figures are untouched, because a domain expiring in 30 days is a scheduled administrative task rather than an outage.

Each threshold alerts once. Renewing the domain re-arms all of them, so next year's warnings fire normally.

An already-lapsed domain still alerts, unlike an already-expired certificate. There is no failed handshake to notice, so this may be the only warning you get. Renew it immediately: after a grace period a lapsed domain enters redemption, which costs considerably more to recover, and after that anyone can register it.

When Pingara Stays Quiet

Not every top-level domain publishes registration data, and some registries answer with nothing usable. Pingara treats that as we could not find out and says nothing, rather than reporting a problem with a domain that is perfectly healthy.

Practical Notes

• Most lapsed domains lapse because auto-renew was off, or the card on file expired. Both are worth checking when the first warning arrives.
• Changing a monitor's URL clears its stored registration data, so the new domain is looked up fresh on the next daily run.

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 Degraded

Timeout - Hard failure threshold (check fails). Degraded - A separate raw-latency rule (check succeeds, but the response took too long). It defaults to firing at 4× your Apdex threshold, but it's its own configurable setting. See Apdex Scoring for how the two relate. Apdex itself never triggers a status change; it's computed only for reporting.

Example:

• Timeout: 30s
• Apdex threshold (T): 500ms → Degraded defaults to firing above 2000ms
• Response: 2s → Check succeeds, but counts toward the Degraded rule

Custom Headers

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 (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