Choose the Observation That Matches the Service
In Uptime Kuma, choosing a monitor is choosing a claim about a service. The useful question is not merely which check can reach the target, but which observation can expose the failure that matters. Understanding the common contract behind Uptime Kuma's monitor types lets the reader make that choice deliberately, while recognizing where a local host, a browser, a push caller, or an external probe changes the evidence.
A service contract is simply the condition that must be true for a service to be useful. A web server may need to return an accepted status and a meaningful page. A DNS service may need to return a particular record. A container may need to be running and healthy. A scheduled job may need to report completion from its own environment. These are different conditions, even when all of them are casually described as “up.”
The common contract behind different checks
Uptime Kuma's monitor types share a simple boundary. A type-specific check performs the observation. If the configured condition passes, it supplies an UP heartbeat and a response time. If it cannot establish success, it throws an error with a useful message. The central monitor loop then handles the common consequences: retries, status classification, notification decisions, statistics, persistence, and delivery to the interface.
This split is more important than the names of the individual types. Without it, every new kind of check would need to implement its own retry rules, history format, dashboard update, and alert behavior. With it, the part that knows how to speak DNS can remain focused on DNS, while the part that knows how to manage a heartbeat can treat the result consistently. A browser navigation and a TCP connection can therefore appear in the same dashboard without pretending that they tested the same thing.
The boundary also prevents a common category error. The shared result does not mean shared proof. UP means that the particular implementation completed its configured assertion from its configured vantage point. For a basic HTTP monitor, that may mean the response passed the accepted status-code test. For a keyword monitor, it additionally means the response contained—or, if configured, did not contain—the required text. For a JSON query, it means a selected value could be compared with an expected value. The word UP is a common output vocabulary, not a universal definition of health.
Consider a small online store. Its home page can return status 200 even while the checkout service is failing. A plain HTTP check would provide evidence that the home-page endpoint answered successfully. That is not a useless result; it answers a narrow question. But if the important failure is an error message in the response, a keyword check may be more revealing. If the endpoint returns structured data such as {"state":"ready"}, a JSON query can test the value rather than merely the transport. If checkout is a separate host, the correct design may require another monitor rather than a more elaborate assertion on the home page.
This is why the monitor abstraction is a mechanism for preserving differences, not hiding them. The common heartbeat makes results comparable at the system boundary. The type-specific assertion determines what the comparison is allowed to mean.
The contract has a practical consequence for errors. A check should fail with enough context to explain what it tried to establish. A DNS monitor can include the records it received. A content check can report that the status code was acceptable but the expected content was absent. A container check can distinguish a stopped or paused container from one that is restarting. These messages travel with the heartbeat for private diagnosis, while later public projections may intentionally hide them.
The contract is also extensible. Uptime Kuma's central loop recognizes registered monitor types and can apply the same lifecycle around them. A type may support additional conditions or a custom status when the meaning requires it, but the normal success path still returns to the common heartbeat. This is a useful design compromise: new protocols can be added without making the rest of the application protocol-aware, while the shared pipeline retains a stable place to apply policy.
Match the probe to the failure you care about
The easiest way to choose among monitor types is to move from the outside of a service toward the condition that matters. Each additional assertion can provide stronger evidence, but it can also become more specific, more fragile, or more dependent on a particular representation.
Reachability and protocol. Ping and TCP-style checks answer whether packets can reach a host or a port can complete its connection. They are valuable for network paths, firewalls, listening services, and basic infrastructure. They do not prove that an application understands the request correctly. A port can be open while the process behind it is stuck, returning errors, or serving the wrong data.
HTTP response and content. An HTTP monitor can evaluate response status against configured accepted ranges, follow the request's method and options, and measure the response time. This is a better fit when the service contract is “this endpoint responds with an acceptable result.” A keyword assertion adds content semantics: the response must contain a chosen string, or must not contain it when the match is inverted. That distinction catches a common failure mode in which an application returns a technically successful page containing an error state.
There is a trade-off. Content assertions depend on wording and representation. A harmless redesign can remove a phrase and create an alert; a response can retain the phrase while a deeper workflow is broken. The assertion is stronger than reachability for the failure it names, but narrower than an end-to-end test. The right response is not to avoid content checks. It is to choose a stable signal that belongs to the service contract, and to understand what its absence or presence means.
Structured responses. JSON-query monitoring is useful when the meaningful condition is a value inside structured data. Uptime Kuma first treats the response as JSON when possible, evaluates a query, and compares the resulting primitive with an expected value using operators such as equality, inequality, ordering, or containment. It rejects an undefined result, an array, or an object when the configured comparison requires a single value. That restriction is conceptually helpful: the monitor must say which value it is judging rather than quietly comparing an entire, changing document.
Suppose an API returns a deployment state, a queue depth, or a readiness flag. Testing that field can detect a service that is responding but not ready. It still does not prove that every dependent component is correct. It proves that one structured response, seen from one probe, satisfied one comparison. If the API changes its schema, the monitor may fail because the assertion no longer maps to the intended value. That is a signal to review the contract, not automatic evidence that the service itself is down.
DNS records. A DNS monitor asks a different question again. It chooses a record type, resolves the target through configured resolver servers, records the lookup duration, and can evaluate conditions against returned records. For a CNAME, the expected value may be a particular name. For an A, AAAA, TXT, MX, or other record, the relevant evidence may be whether any returned value matches the configured condition. This can expose an incorrect migration, a stale record, or a resolver-specific problem that an HTTP request to the final destination would conceal.
The resolver is part of the observation path. Uptime Kuma may resolve configured resolver hostnames before using them, and an invalid or unreachable resolver can make the check fail. That failure should not be casually attributed to the domain being monitored. The monitor tells the operator that the intended DNS observation could not be completed from the selected resolver path. Where DNS correctness is important across regions or networks, one local resolver is only one perspective.
Container state. A Docker monitor shifts the target boundary inside the operator's environment. It asks a Docker daemon for container information, then distinguishes conditions such as stopped, paused, restarting, and unhealthy. When a container is running without a health check, the implementation treats it as up but explicitly says that visibility would be better with a health check. That is a valuable qualification: process existence and application health are not the same evidence.
The Docker daemon connection is itself a dependency. It may use a local socket or a TCP endpoint, potentially with client certificates. A failure to reach the daemon can look like a monitor failure even when the container would be healthy if inspected directly. The operator therefore has to protect the daemon access granted to the monitoring process and include that access path in the trust model.
Browser navigation. A real-browser monitor measures something closer to page navigation than a raw HTTP client does. It launches or connects to Chromium, opens a new browser context, waits for network idle, records navigation timing, and takes a screenshot. It accepts only HTTP and HTTPS URLs. This can reveal failures involving browser-facing delivery, redirects, or resources needed before the page settles.
It also introduces more moving parts. Chromium must be available and usable, the browser process consumes more resources than a simple request, and a remote browser makes the path cross another service. The resulting screenshot is useful diagnostic evidence, not a complete representation of every user's experience. A browser monitor can confirm that one controlled navigation succeeded; it cannot model every device, extension, regional network, or interaction.
Push reporting. A push monitor reverses the direction of observation. Instead of Uptime Kuma initiating the check, another job or system reports a heartbeat through a push endpoint. This fits batch work, backups, imports, or scheduled tasks whose success is best known by the task itself. The monitor checks whether a report arrives within the expected window. If the report is late or absent, the result becomes a failure according to the monitor's timing and retry policy.
The caller becomes part of the evidence chain. A push success can mean that the reporting job reached Uptime Kuma and sent the expected status; it does not independently prove that the job's downstream effects are correct. A down report may be explicit, while silence may be ambiguous: the job could have failed, the scheduler could be paused, the network could be broken, or the monitoring endpoint could be unreachable. Push monitoring is powerful because it places knowledge at the source of the work, but it must be paired with an understanding of what the caller actually knows.
Remote measurements. Globalping-backed monitors ask community-hosted probes to perform ping, HTTP, or DNS measurements from a selected location. This can add a perspective that the local Uptime Kuma host cannot provide. A service may look healthy from a data center while users in another region cannot reach it. A remote measurement can make that difference visible.
The price is a new trust boundary. Uptime Kuma must create and retrieve a measurement through the external API, the selected probe must run it, and the returned result must be interpreted. The API can fail or rate-limit requests, and the community probe is not under the operator's direct control. A remote UP is therefore evidence from a useful vantage point, not a replacement for understanding the measurement service or for testing the local path.
These examples show why no single probe covers every important failure mode. An operator might use a basic HTTP check for availability, a content or JSON assertion for application readiness, a DNS check for name resolution, and a push monitor for a background job. That is not a recommendation to create monitors indiscriminately. Every monitor consumes storage, probe capacity, attention, and sometimes credentials. The useful rule is to begin with a failure hypothesis: “What could be broken while a simpler check remains green?” Add an assertion or a second vantage point only when it answers that question.
A monitor is strongest when its target, assertion, vantage point, and dependency are explicit. Once the check produces a result, Uptime Kuma still has to decide whether a failure is transient, actionable, or planned. That next decision is where retries and state transitions turn an observation into an outage signal.