Endpoint Monitoring

What counts as an "endpoint"?

An endpoint is anything addressable on the internet that can be polled to verify availability. The classic case is a website URL — but in modern infrastructure, the things you care about are far more varied: REST APIs, GraphQL endpoints, mail servers, database listeners, message queues, container health-check ports, internal admin panels, webhook receivers. DiagnoSEO Uptime Monitoring treats them uniformly: define what "healthy" looks like for that endpoint, schedule a check, get alerted on failure.

This page covers every endpoint type the tool supports, what each is good for, and the signal you get from monitoring it.

HTTP / HTTPS website endpoints

The default case. Enter https://example.com and the monitor performs a GET request on a schedule (1 minute, 5, 10, 30, or 60 minutes depending on plan). A successful check means: TCP connection established, TLS handshake completed (for HTTPS), HTTP response received with an expected status code (default: 2xx or 3xx), and optionally a keyword present (or absent) in the response body. The check captures Time To First Byte, total response time, content size, redirect chain, and the full set of response headers.

HTTP endpoints are the right monitor for: marketing sites, blogs, e-commerce shops, SaaS dashboards, documentation portals, anywhere that humans visit with a browser.

API endpoints (REST / GraphQL / JSON-RPC)

APIs need more than "did it respond" — they need "did it respond correctly". Configure the monitor with custom HTTP method (GET, POST, PUT, DELETE, PATCH), custom headers (auth tokens, content-type), request body (JSON payload for POST/PUT), and JSON assertions against the response (data.status must equal "ok", result.count must be greater than 0, errors[] must be empty). An API returning HTTP 200 with a malformed payload is the worst kind of broken — it looks healthy to a naive monitor but is failing every client. JSON assertions catch this.

See the dedicated API monitoring guide for setup details and assertion syntax.

TCP port endpoints

For non-HTTP services: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), database listeners (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), custom application ports. The monitor opens a TCP connection to the specified host:port and reports success if the connection is accepted within the timeout window. No protocol-level handshake — just "is the daemon listening".

This is the right monitor for any TCP-based service where you care about reachability and don't need protocol-aware checks. For SMTP banner verification or database query-level checks, use the heartbeat monitor instead (your service pings us when it's healthy, see cron-job / heartbeat monitoring).

Ping (ICMP) endpoints

Layer-3 reachability check. The monitor sends an ICMP echo request to the target hostname or IP and waits for the reply. Useful for routers, switches, IoT devices, anything that responds to ping but doesn't run HTTP. Note that many cloud providers (AWS, GCP, Azure) block ICMP by default at the security-group level even when the host is otherwise healthy — for cloud workloads, prefer HTTP or TCP port checks.

Hostname / DNS endpoints

DNS resolution monitoring. The tool periodically resolves your domain's A, AAAA, MX, NS, TXT, and CNAME records, snapshots the results, and alerts when any of them change. Catches: unauthorized DNS hijacks, accidental misconfiguration during DNS provider migrations, third-party services updating their endpoints without notice (your CDN switches IP blocks, for example), MX records being wiped by a typo.

DNS monitoring isn't about availability — your DNS provider is almost certainly more reliable than your origin. It's about detecting change. See DNS change monitoring for the full breakdown.

SSL certificate endpoints

Every HTTPS endpoint gets automatic SSL monitoring on top of its uptime check. The tool reads the certificate, parses the validity period and issuer, and warns at 30, 14, 7, 3, and 1 days before expiry. See SSL certificate monitoring for details.

Domain expiry endpoints

For every monitored URL, the tool also queries WHOIS once per day and tracks the domain registration expiry. Warnings fire at the same thresholds as SSL (30/14/7/3/1 days). Renewal lapses are catastrophic — the domain becomes unowned and someone can register it the moment your grace period ends. See domain expiration monitoring.

Choosing the right endpoint type

If you're not sure which monitor type to use, start with HTTP/HTTPS for anything with a web interface, TCP port for everything else, and add heartbeat checks for batch jobs that don't expose any network surface. You can monitor the same target with multiple types — for instance, a TCP port check on 443 catches "server is up, but TLS handshake broken" cases that an HTTP check on the same URL would also flag, while a heartbeat from your own internal monitoring agent confirms that your application logic is actually running.

Frequently asked questions

• What counts as an endpoint?

  Anything addressable on the internet: HTTP/HTTPS URLs, REST APIs, TCP ports (SMTP, MySQL, custom), ping-able hostnames, DNS records, SSL certificates, and domain registration entries. Configure one monitor per endpoint type.

• Should I use HTTP check or TCP port check?

  HTTP is the right default for any web service. TCP port is better for non-HTTP services (databases, mail servers, custom protocols) where you only care about "is the daemon accepting connections". Use TCP for low-level reachability, HTTP for "is the application actually responding correctly".

• How do heartbeat (cron-job) monitors differ?

  Heartbeat is reversed — instead of us polling your service, your service pings us at a known URL. If we don't get the ping within the expected window, we alert. Used for cron jobs, batch processes, and anything that runs on a schedule without a network surface to check.

• Can one URL have multiple monitors?

  Yes. You can monitor the same target with different check types — e.g. HTTP check for full availability plus a TCP port 443 check that catches TLS-handshake issues. Each monitor runs independently and alerts independently.

• Do I need to monitor SSL and domain separately?

  No — every HTTPS endpoint automatically gets SSL monitoring on top of its uptime check, and every monitored URL gets daily domain-expiry tracking. Both are included, no extra configuration. Domain monitoring is per-domain — multiple monitors on the same domain share the WHOIS data.