Monitors

Monitor types

HTTP Check (http_check)

Sends a configurable HTTP request to a URL and checks the response status code against an expected value. This is the most common monitor type — use it for web endpoints, APIs, and health-check URLs.

• Target — a full URL including scheme, for example https://api.example.com/health.
• Method — HTTP method to use: GET, POST, PUT, or DELETE. Defaults to GET.
• Headers — optional request headers, one per line in Header: Value format (for example Authorization: Bearer token).
• Request body — optional body sent with the request (useful with POST or PUT).
• Expected status — the exact HTTP status code the check must receive. Defaults to 200. Any other status is treated as down.
• Timeout — how long to wait for a response. Defaults to 10 000 ms (10 seconds). A timeout results in inconclusive, not down.
• Response time — measured end-to-end from request send to last byte received.
• Supports availability SLO and latency SLO (Business and Founder plans).

The check reports down when the response status differs from the expected value. It reports inconclusive when the request times out or fails to connect after a retry — meaning the checker itself couldn't reach the target. Inconclusive results are visible in check history but do not count toward uptime percentage or open incidents. HTTP Check does not capture TLS certificate details for https:// targets — use an SSL Certificate Check for that.

ICMP Ping (icmp_ping)

Sends ICMP echo requests to a hostname or IP address and waits for a reply. Use this to verify network-layer reachability when HTTP-level checks are too high in the stack.

• Target — a hostname or IP address, for example db.example.com.
• Supports availability SLO (Business and Founder plans).
• Latency SLO is not available for ICMP monitors.

SSL Certificate Check (ssl_check)

Connects to a hostname on port 443 and inspects the TLS certificate. Reports down when the certificate has expired or will expire within the warning window (default: 30 days).

• Target — a hostname, for example example.com. Do not include https://.
• Supports availability SLO (Business and Founder plans).
• Available on Pro plan and above.

TCP Port Check (tcp_check)

Opens a TCP connection to a host and port. If the connection succeeds, the target is up. If the connection is refused, the target is down. If the connection times out after a retry, the check returns inconclusive. Use this to monitor any TCP-based service — game servers, databases, message queues — where an HTTP check is not appropriate.

• Target — host and port in host:port form, for example mc.example.com:25565 (Minecraft Java Edition), db.internal:5432 (PostgreSQL), or cache.internal:6379 (Redis). Do not include a URL scheme.
• Timeout — how long to wait for the connection to complete. Defaults to 5 000 ms (5 seconds). A timeout results in inconclusive after retry, not down.
• Response time — measured from the start of the dial to the moment the connection is established.
• Supports availability SLO (Business and Founder plans).

The check reports down when the connection is refused (port closed). It reports inconclusive when the connection times out (firewall silently drops the packet) or the hostname cannot be resolved after a retry — these indicate our checker couldn't reach the target, not that the target is definitively down. It does not send any bytes after connecting — it is a pure reachability probe.

UDP Check (udp_check)

Sends a UDP payload to a host and port and validates the response. Because UDP is connectionless, a bare "send empty packet, wait" check cannot distinguish a live service from a firewall silently dropping traffic. UDP Check solves this with two operating modes:

• Target — host and port in host:port form, for example valheim.example.com:2457. Do not include a URL scheme.
• Timeout — how long to wait for a response. Defaults to 5 000 ms (5 seconds). A timeout results in inconclusive after retry, not down.
• Supports availability SLO (Business and Founder plans).

Mode: preset (recommended)

The checker sends a protocol-specific request and validates that the response matches the expected shape. Use this for known protocols — it is more reliable than raw mode because it confirms the service is actually alive and responding correctly, not just that some bytes came back.

Available presets:

source_a2s_info — Steam Source engine games

Sends the Steam A2S_INFO query (0xFF 0xFF 0xFF 0xFF 0x54 + "Source Engine Query\0") and validates that the response begins with the A2S info magic (0xFF 0xFF 0xFF 0xFF 0x49). Post-2020 Source servers issue a challenge (0x41) before responding; the checker handles this automatically.

Covered games and their typical query ports:

• Valheim — query port is game port + 1 (default game 2456 → query 2457)
• Counter-Strike: GO / CS2 — query port same as game port (default 27015)
• Rust — query port same as game port (default 28015)
• ARK: Survival Evolved / Ascended — query port same as game port (default 27015)
• Garry's Mod — query port same as game port (default 27015)
• DayZ — query port same as game port (default 2302)
• Squad — query port same as game port (default 27165)
• Any other Steam multiplayer game using the Source query protocol

Check the game's documentation for the exact query port — some games use a separate query port while others reuse the game port. The Steam documentation at developer.valvesoftware.com/wiki/Server_queries has protocol details.

minecraft_bedrock_query — Minecraft Bedrock Edition

Sends the RakNet Unconnected Ping packet (32 bytes, type 0x01) and validates that the response is an Unconnected Pong (0x1C) containing the RakNet offline magic at offset 17. No challenge dance is required.

Default port: 19132 (UDP). Use host:19132 as the target.

Not covered: Minecraft Java Edition uses the TCP Server List Ping protocol and is not a UDP service.

quake3_status — Quake III / GameSpy 1 compatible engines

Sends the out-of-band getstatus query (0xFF 0xFF 0xFF 0xFF getstatus\n, 14 bytes) and validates that the response starts with the OOB header (0xFF 0xFF 0xFF 0xFF) and contains the substring statusResponse in the first 50 bytes.

Covered engines and typical ports:

• Quake III Arena — default port 27960
• OpenArena — default port 27960
• Urban Terror — default port 27960
• ioquake3 derivatives — same OOB protocol

dns_a_query — DNS resolver health check

Sends a well-formed DNS A-record query for example.com (transaction ID 0x1234, recursion desired) and validates that the response echoes the same transaction ID with the QR bit set (confirming it is a response, not a query). The answer content is not validated — any response confirms the resolver is processing queries.

Default port: 53 (UDP). Target public resolvers with 1.1.1.1:53 or 8.8.8.8:53, or your own resolver.

ntp_query — NTP time server health check

Sends a 48-byte NTPv4 client request (byte 0 = 0x23: LI=0, VN=4, Mode=3) and validates that the response is exactly 48 bytes with mode=4 (server) and a valid stratum (1–15).

Default port: 123 (UDP). Use targets like time.cloudflare.com:123 or pool.ntp.org:123.

Mode: raw

You supply the exact bytes to send (as hexadecimal). Any response received within the timeout is treated as up. Useful for custom or proprietary UDP protocols where you know your service replies to a specific packet. Payload must decode to at most 1 280 bytes (the IPv6 minimum MTU) to avoid IP fragmentation.

Example: to send 0xDEADBEEF set payload_hex to deadbeef.

Heartbeat (heartbeat)

Instead of probing an external URL, a Heartbeat monitor waits for your service to ping Nines. If no ping arrives within the grace period, Nines treats it as down. Use this for cron jobs, background workers, and scheduled tasks that must run on time.

• Heartbeat URL — a unique URL you copy from the monitor detail page and call (HTTP GET or POST) at the end of each successful run.
• Grace period — how long Nines waits after the expected ping time before opening an incident. Set this to a value slightly longer than the maximum acceptable jitter in your job schedule.
• Supports availability SLO (Business and Founder plans).

Check intervals

The interval controls how frequently each region probes the target. Shorter intervals detect outages faster and give you more data points for SLO calculations, at the cost of slightly more probe traffic to your endpoints.

• 30 seconds — fastest available; requires Business or Founder plan.
• 60 seconds — available on Pro plan and above.
• 5 minutes — available on all plans including Free.
• 10 minutes — slowest available; suitable for rarely-changing targets.

Regions

Each monitor runs its checks from every selected region in parallel. Nines opens an incident only when all selected regions agree that the target is down — this avoids false positives from transient regional network issues. A region that returns inconclusive (checker couldn't reach the target) does not contribute to incident creation and does not count against uptime.

See Regions for the full list of available regions and guidance on choosing the right set for your deployment.