Monitors

Every monitor type — HTTP, TCP, DNS, databases, infrastructure protocols, heartbeats, agents — plus grouping and ordering.

Monitor types

Type What it checks
http / https HTTP status code, latency, optional body/keyword matching
ping / icmp ICMP echo reachability
tcp TCP port connectability
udp UDP port reachability
dns DNS resolution and expected records
smtp / pop3 / imap / telnet Mail and legacy service checks
postgres / mysql / redis Database connection checks
ssl TLS certificate validity and expiry
domain Domain expiry
heartbeat Reverse check — your job pings us, silence means down
agent Metrics from a ShxrkSystems agent on your server
api Push-based API monitoring — see API Monitoring
game_server Game server query or push metrics — see Game Server Monitoring
composite Synthetic parent — derives status from several child monitors

Infrastructure monitor types

These types speak native protocols and are executed by your agents — they monitor what external probes cannot reach:

Type What it checks
docker Docker daemon container states
podman Podman container states
docker_swarm Swarm service replica health
kubernetes Pod/deployment status via the K8s API
proxmox Proxmox VM/LXC states
vmware VMware VM states
ceph Ceph cluster health
rabbitmq RabbitMQ node/queue health via the management API
kafka Kafka broker connectivity and topic state
mqtt MQTT broker connect + optional topic publish/subscribe round-trip
snmp SNMPv2c device queries (switches, printers, UPS)
network_device Generic network device checks

Infrastructure credentials (SNMP community strings, MQTT/Kafka/RabbitMQ logins) are stored encrypted, never returned in monitor list responses, and redacted for team members without settings-management permission.

Groups and ordering

Monitors can be grouped (monitor_groups) and both groups and the monitors inside them have an explicit display order. The order you set in the dashboard is the order shown on the public status page:

PUT /api/v1/uptime/monitors/order
{ "monitors": [ { "id": "<uuid>", "order": 0 }, ... ] }

PUT /api/v1/uptime/groups/order
{ "status_page_id": "<uuid>", "groups": [ { "id": "<uuid>", "order": 0 }, ... ] }

Both update every row inside a single transaction — partial updates never leave a scrambled order — and invalidate the public status page cache immediately. New monitors are appended at the end of their group automatically.

HTTP monitors

HTTP monitors support:

  • Method selection (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS), custom headers and request body
  • Expected status code (expected_status) and body matching (contains, exact, regex, not_contains)
  • Keyword checks via expected_keywords
  • Redirect following (follow_redirects) and TLS verification (verify_ssl)
  • Latency threshold (latency_threshold_ms) — beyond it a monitor reports degraded

Failure and recovery detection

Monitors do not flip on a single failed check:

  • failure_threshold — consecutive failed checks required before a monitor is marked down (1–20)
  • recovery_threshold — consecutive successful checks required before it recovers (1–20)
  • degraded_timeout_seconds — heartbeat-style timeout for push monitors
  • Outages require regional quorum — a single checker's view is never enough to declare a global outage, which prevents false alarms from network paths or individual regions

Intervals and tiers

The minimum check interval depends on your plan: Free plans check every 300s, paid plans down to 30s. Per-tier limits are listed on the pricing page.

Heartbeat monitors

For cron jobs and scheduled tasks: create a heartbeat monitor, then call its push URL from your job:

POST https://api.shxrk.systems/api/v1/uptime/heartbeat/<monitor_id>
Authorization: Bearer <heartbeat_token>

If no heartbeat arrives within expected_interval seconds, the monitor goes down.

PreviousGetting StartedNextStatus Pages