Uptime & HTTP Checks
How checks work
Every monitor check follows this sequence:
1. DNS resolution (measured separately)
2. TCP handshake
3. TLS handshake (HTTPS)
4. Send HTTP request
5. Read first byte (TTFB)
6. Read full response body
7. Keyword match (if configured)
8. Record: status code, total time, TTFB, TLS gradeAll timing phases are stored individually so you can diagnose where latency comes from.
Response time breakdown
| Phase | Metric | What it tells you |
|---|---|---|
| DNS | dns_ms | Slow → bad TTL, wrong resolver |
| TCP connect | connect_ms | Slow → server overload, routing |
| TLS | tls_ms | Slow → heavy cert chain, no session resumption |
| TTFB | ttfb_ms | Slow → slow app, no caching |
| Transfer | transfer_ms | Slow → large payload, no compression |
| Total | duration_ms | End-to-end user experience |
SSL / TLS grading
We grade SSL using the same methodology as SSL Labs:
| Grade | Criteria |
|---|---|
| A+ | TLS 1.3 only, HSTS, perfect forward secrecy, OCSP stapling |
| A | TLS 1.2+, strong ciphers, no known vulnerabilities |
| B | TLS 1.2+ but some weak ciphers or missing HSTS |
| C | Supports TLS 1.0 or weak DH parameters |
| F | Critical vulnerability (Heartbleed, POODLE, etc.) or expired cert |
⚠️
Certificates expiring in < 14 days trigger an alert regardless of grade.
Keyword monitoring
You can require a string to be present (or absent) in the response body:
Keyword: "status":"ok" → present
Keyword: "maintenance mode" → must be absentUseful for:
- Health check endpoints that return JSON
- Pages that should not show error messages
- Detecting when a WAF injects a block page
HTTP headers check
SecureCheap checks for the following security headers on every HTTP monitor:
| Header | Expected |
|---|---|
Strict-Transport-Security | max-age≥31536000 |
X-Content-Type-Options | nosniff |
X-Frame-Options | DENY or SAMEORIGIN |
Content-Security-Policy | Any value present |
Referrer-Policy | Any value present |
Missing headers contribute to your Security Score.