PeekPilot

How PeekPilot Uptime Monitoring Works

A transparent look at the checks, confirmation rules, and security controls powering the monitoring service.

1 Lightweight Scheduled Polling

Standard monitoring tools can execute unnecessarily heavy requests that inflate server load. PeekPilot uses bounded GET requests with strict connection and response timeouts, treats HTTP redirects as reachable without following them into a different network target, and caps the response body it reads.

Even at the fastest one-minute plan interval, each check is designed to remain lightweight while still verifying the actual HTTP response and detecting parked-domain pages.

2 The False-Positive Mitigation Engine

The biggest problem with cheap monitoring tools is "alert fatigue" caused by false positives (e.g., a momentary DNS routing delay triggering a downtime alert). PeekPilot requires three consecutive failed checks before confirming an outage.

flowchart TD A[Scheduled Check] -->|Returns 5xx or Timeout| B[Failure 1 - no alert] B --> C[Retry after 1 minute] C -->|Fails again| D[Failure 2 - no alert] D --> E[Retry after 1 minute] E -->|Third failure| F[Downtime Logged and Alert Sent] C -->|Successful response| G[Counter Reset] E -->|Successful response| G

If a check fails, PeekPilot records the observation and retries after one minute without changing the public status or sending an alert. Only a third consecutive failure opens an incident; any successful response resets the counter immediately.

3 Read-Only WordPress Architecture

When you install the PeekPilot companion plugin for deep WordPress metrics (like database connection status and plugin versions), it exposes a secured REST API endpoint on your site. This endpoint is strictly read-only.

PeekPilot cannot execute arbitrary PHP code, it cannot write to your database, and it cannot modify your files. The architecture guarantees zero supply-chain risk.

4 Cryptographic SSL Handshake Analysis

Rather than relying on simple port 443 pings, PeekPilot initiates a full TLS handshake during every check cycle. We extract the raw X.509 certificate data and calculate the delta between the NotAfter timestamp and the current UTC time. If this delta drops below 7 days, an automatic alert is dispatched, giving you a full week to resolve auto-renewal failures.