Configure and use HTTP/HTTPS monitoring for websites, APIs, and web endpoints including authentication, custom headers, and POST data.

HTTP Monitoring

HTTP monitoring in UptimeHunt provides comprehensive website and API endpoint monitoring capabilities. This guide covers configuration, authentication, advanced features, and best practices for HTTP/HTTPS monitoring.

Basic Configuration

Required Parameters

Service Name — Descriptive identifier for the monitoring service. Example: "Production API Health Check".

URL — Complete endpoint URL including protocol. Format: https://example.com/path. Supports both HTTP and HTTPS. Maximum length: 4096 characters.

HTTP Method — Request method to use for checks. Options: GET, POST, HEAD. Default: GET.

Optional Parameters

Project — Project assignment for organization.

Enabled — Toggle to activate/deactivate monitoring.

Check Interval — Monitoring frequency in seconds. Default: 180 s (3 min). Minimum is plan-dependent (Free: 300 s, Pro: 60 s, Team: 30 s, Enterprise: 10 s).

HTTP Methods

GET

Standard method for retrieving resources.

Use Cases:

Website homepage monitoring
API endpoint availability
Health check endpoints
Status pages

Configuration:

No request body required
Can include custom headers
Supports authentication

POST

Method for sending data to endpoints.

Use Cases:

API endpoint testing with data
Login endpoint validation
Form submission monitoring
Data processing endpoints

Configuration:

Requires request body data
Supports JSON, XML, form data
Can include custom headers
Supports authentication

HEAD

Lightweight method requesting only headers.

Use Cases:

Quick availability checks
Metadata verification
Reduced bandwidth monitoring
Response header validation

Configuration:

No response body retrieved
Faster than GET
Limited validation options

Authentication

UptimeHunt supports multiple authentication methods for protected endpoints.

No Authentication

Default setting for public endpoints.

Configuration:

Select "None" from authentication dropdown
No additional parameters required

Use When:

Monitoring public websites
Accessing open APIs
Checking unauthenticated endpoints

Basic Authentication

HTTP Basic Authentication using username and password.

Configuration:

Select "Basic" from authentication dropdown
Enter Username
Enter Password

Technical Details:

Credentials sent in Authorization header
Base64 encoded username:password
Supported by most web servers
Standard HTTP authentication method

Example Use Cases:

Admin panels with basic auth
Development/staging environments
Legacy systems
Simple authentication requirements

Security Considerations:

Always use HTTPS with Basic Auth
Credentials transmitted with every request
Create dedicated monitoring credentials
Limit credential permissions

Bearer Token

Token-based authentication for modern APIs.

Configuration:

Select "Bearer Token" from authentication dropdown
Enter your Bearer Token

Technical Details:

Token sent in Authorization header
Format: Authorization: Bearer <token>
Common in RESTful APIs
JWT token support

Example Use Cases:

Modern REST APIs
Microservices
OAuth 2.0 protected resources
JWT-authenticated endpoints

Security Considerations:

Tokens may expire (plan for rotation)
Use HTTPS to protect tokens
Generate dedicated monitoring tokens
Limit token permissions/scopes

Custom Headers

Add custom HTTP headers to requests for specialized monitoring scenarios.

Adding Headers

In service configuration, locate Headers section
Click "Add Header" button
Enter Header Name (e.g., Accept)
Enter Header Value (e.g., application/json)
Repeat for additional headers

Common Headers

Content-Type

Name: Content-Type
Value: application/json

Specifies request body format for POST requests.

Accept

Name: Accept
Value: application/json

Indicates expected response format.

User-Agent

Name: User-Agent
Value: UptimeHunt-Monitor/1.0

Identifies the monitoring client.

API-Key

Name: API-Key
Value: your-api-key-here

Custom API key authentication.

X-Custom-Header

Name: X-Custom-Header
Value: custom-value

Application-specific headers.

Header Limitations

Maximum header name length: 64 characters
Maximum header value length: 4096 characters
No limit on number of headers (reasonable use)

Use Cases

API Version Selection

Name: API-Version
Value: v2

Content Negotiation

Name: Accept-Language
Value: en-US

Custom Authentication

Name: X-API-Token
Value: token-value

Correlation Tracking

Name: X-Request-ID
Value: monitoring-check-id

POST Data

For POST requests, configure the request body.

Text Input

Enter request body directly in the form field.

Supported Formats:

JSON
XML
Form-urlencoded
Plain text

JSON Example:

{
  "username": "monitor",
  "password": "check123"
}

XML Example:

<?xml version="1.0"?>
<check>
  <status>request</status>
</check>

Form Data Example:

username=monitor&password=check123

File Upload

Upload a file containing the request body.

Use Cases:

Large request bodies
Complex JSON/XML structures
Binary data
Reusable request templates

Process:

Prepare request body in a file
Click file upload button
Select file from your computer
File content used as POST body

File Limitations

Uploaded files should be reasonable in size. Extremely large payloads may cause timeout or performance issues.

Content-Type Header

Always set appropriate Content-Type header for POST data:

For JSON:

Content-Type: application/json

For XML:

Content-Type: application/xml

For Form Data:

Content-Type: application/x-www-form-urlencoded

IP Address Family

Control which Internet Protocol versions the prober uses to connect to your HTTP endpoint.

Address Family Options

Auto (Default)

The prober resolves the hostname and dials using the operating system's default behavior (CURL_IPRESOLVE_WHATEVER). No per-family result breakdown is reported.

Use When:

No specific IPv4/IPv6 requirement
Target has both IPv4 and IPv6 support
Backward compatibility preferred

IPv4 Only

The prober forces IPv4 resolution only. DNS is checked for an A record; if no A record exists, the check fails with a no_record error (distinct from dns or timeout).

Use When:

IPv6 is not available or disabled
Specific IPv4 testing required
Legacy infrastructure

IPv6 Only

The prober forces IPv6 resolution only. DNS is checked for an AAAA record; if no AAAA record exists, the check fails with a no_record error.

Use When:

Testing IPv6 deployment
IPv4 has been deprecated
Specific IPv6 infrastructure

Both IPv4 and IPv6

The prober dials both IPv4 AND IPv6 independently and reports separate metrics for each family under response.families.ipv4 and response.families.ipv6. The overall check succeeds only if BOTH families are reachable (AND rule). The top-level response.time_ms always deterministically mirrors the IPv4 (primary) family — it is never a race for whichever family answered first.

Use When:

Rolling out IPv6 (AAAA records)
Monitoring dual-stack deployments
Detecting per-family issues independently

Both-Mode Details

In "both" mode, each family reports its own result object under response.families.<family> (<family> is ipv4 or ipv6):

Per-Family Fields

response.families.<family>.reachable — whether that family connected successfully
response.families.<family>.time_ms — that family's response time in milliseconds (a flat number)
response.families.<family>.ip — the IP address that family resolved and dialed
response.families.<family>.error — error detail when that family failed; absent/null on success

There is no per-family HTTP status field — response.families.<family>.status does not exist. Status-code assertions read only the top-level response.http_status_code, which reflects the primary (IPv4) family's response.

Per-Family Assertions

Configure assertions against either family independently:

Assertion type	Result path
`ipv4_reachable`	`response.families.ipv4.reachable`
`ipv6_reachable`	`response.families.ipv6.reachable`
`ipv4_response_time_ms`	`response.families.ipv4.time_ms`
`ipv6_response_time_ms`	`response.families.ipv6.time_ms`
`ipv4_address`	`response.families.ipv4.ip`
`ipv6_address`	`response.families.ipv6.ip`

Assertion family must be covered by the address family setting

A per-family assertion is only valid when the service's address family setting covers that family: ipv4_* assertions need ipv4 or both; ipv6_* assertions need ipv6 or both. Saving an assertion for an uncovered family (e.g. ipv6_reachable on a service set to auto or ipv4) is rejected with a 400.

Both mode doubles the work, not the interval

Families are dialed sequentially, each allotted the full configured timeout — worst case, a "both" check can take up to 2× the timeout to complete. Keep this in mind before setting a short check interval. The full request also runs once per family per cycle: an endpoint monitored with a POST body receives that body twice per cycle — once for IPv4, once for IPv6.

Example Scenario: AAAA Rollout

When rolling out IPv6 (AAAA DNS record), use "both" mode to detect IPv6-specific issues without alarming IPv4 users:

Create a duplicate HTTP check with address family set to "IPv6 Only"
Configure alerts only on the IPv6 check
As IPv6 stabilizes, migrate the main check to "Both" mode
Now both families are monitored, but you have visibility into per-family problems:
- IPv4 slow? — Only the IPv4 family fails
- IPv6 unreachable? — Only the IPv6 family fails
- Both healthy? — Green across the board

This avoids cascading alert fatigue during infrastructure transitions.

Response Validation

Status Code Checking

UptimeHunt checks HTTP response status codes:

Successful Responses:

2xx codes (200, 201, 204, etc.)
3xx codes (301, 302, 304, etc.)

Failed Responses:

4xx codes (400, 401, 403, 404, etc.)
5xx codes (500, 502, 503, 504, etc.)
Connection errors
Timeout errors

Response Time

Response time is measured and recorded:

Time from request initiation to full response
Measured in seconds
Timeout: Configurable (default: 10 seconds)
Historical data available

Connection Validation

Checks verify:

DNS resolution successful
TCP connection established
TLS/SSL handshake completed (HTTPS)
HTTP response received

Advanced Configuration Examples

Monitoring Authenticated API

Name: Production API Health
URL: https://api.example.com/v1/health
Method: GET
Authentication: Bearer Token
Token: eyJhbGciOiJIUzI1NiIs...
Headers:
  - Accept: application/json
Interval: 3 minutes

Name: User Login Test
URL: https://app.example.com/api/login
Method: POST
Authentication: None
Headers:
  - Content-Type: application/json
POST Data: {"email":"test@example.com","password":"test123"}
Interval: 5 minutes

Monitoring with Custom Headers

Name: Versioned API Endpoint
URL: https://api.example.com/users
Method: GET
Authentication: Basic
Username: apiuser
Password: ********
Headers:
  - API-Version: v2
  - Accept: application/json
  - X-Client-ID: monitoring
Interval: 3 minutes