Uptime Monitoring

Scheduled HTTP and TCP checks against any endpoint you choose.

Uptime Monitoring runs scheduled HTTP(S) or TCP checks against any target you point it at, most commonly your own product's public endpoints, and shows whether they're up, how fast they respond, and how that's trended over time. It's independent of the Integrations page's own connector health-checks, since those check a connected tool KubeWatch already knows about, while this checks whatever address you give it. There's no plan-tier gate, since it's available on every plan. Any org member can view checks and results, but creating, editing, deleting, or enabling/disabling a check requires the admin role.

Adding a check

Click Add check and pick HTTP(S), TCP, or Catchpoint (to import an existing Catchpoint test rather than have KubeWatch probe something itself).
Fill in the Target, a full URL for an HTTP check (https://example.com/health), or a host:port pair for TCP.
For an HTTP check, set the HTTP method (defaults to GET) and the expected status range (defaults to 200-299), any response outside that range counts as a failed check.
Set the check interval (how often it runs, minimum 30 seconds) and timeout (how long to wait before giving up on one attempt).
Click Save.

The check's type can't be changed after creation, since it determines which probe logic runs. Delete and re-add it under the correct type instead.

Reading a check's status

Each check shows a status dot (green for up, red for down), its most recent latency, and, if the last attempt failed, the error. Click a check's name to expand it and see the uptime percentage and a recent-results table, timestamp, success or failure, latency, and either the HTTP status code or the error, for whichever attempt.

An HTTP check follows redirects by default, so a target that redirects to HTTPS (a common setup for a bare domain) still passes, as long as the final response's status code falls inside the expected range. TLS certificate validation is skipped the same way every other outbound probe in KubeWatch is, since the point is checking whether the target responds and how fast, not whether its certificate chain is trusted.

Running a check on demand

Click the refresh icon on any check to run it immediately rather than waiting for its next scheduled interval. This is available to any org member, not just admins, the same way pinging an integration already works.

Reaching a target on a private network

Checks run from KubeWatch's own servers on KubeWatch Cloud, so a target needs to be reachable from the public internet, either directly or through a firewall rule or VPN/peering connection. On a self-hosted install, checks run from the synthetics container itself, already inside your network, so anything reachable from that container works, private IPs included.

Importing a Catchpoint test

If you already run tests in Catchpoint, add a check with type Catchpoint and provide the test's ID and a Catchpoint API key (Catchpoint Portal → Settings → Integrations → REST API → Add Consumer). Rather than KubeWatch probing anything itself, it pulls that test's availability and response-time data from Catchpoint on the check's own interval and reports it the same way a native check would, success requires 100% availability across the window; anything less shows as down, with the actual percentage in the error detail.

Importing a Catchpoint test requires `SYNTHETICS_VAULT_MASTER_KEY` to be configured on your KubeWatch instance, since the API key is encrypted at rest. Plain HTTP(S)/TCP checks need no such configuration, since they store no credential at all.

What's next

Uptime Monitoring today covers scheduled HTTP(S)/TCP checks and Catchpoint test imports, with a 30-day result history.