Integrations

Connect KubeWatch to external systems to monitor their health.

The Integrations page connects KubeWatch to external systems so it can monitor their health and pull metrics. These are monitoring integrations (to configure alert notifications, see Alerts → Notifications).

Supported integrations

PostgreSQL, MySQL, Redis, Kafka, Prometheus, Grafana, Jaeger, Zipkin, Argo CD, Jenkins, Java / Spring, Django, Apollo, Active Directory, and VictoriaMetrics.

Adding an integration

Click Add integration and pick a type.
Fill in the connection fields, typically Host, Port, Username, Password, and a TLS toggle.
Click Save & connect.

Use Ping on an integration to check connectivity at any time. Once connected, KubeWatch reads health and metrics from the target and surfaces them in the dashboard. Click an integration's name (or open it directly) to see its full detail page: connection info, uptime, and the same live metrics panel shown on its card, at full size.

The **Host** field wants a bare hostname or IP, not a full URL: `db.example.com`, not `https://db.example.com/`. Pasting one in with a scheme or trailing slash is normalized automatically before KubeWatch attempts to connect, but the port always comes from the separate **Port** field, so leave any port out of the host itself too.

For HTTP-based integrations (Jenkins, Argo CD, Apollo, Django, Java/Spring, Prometheus, Grafana, Jaeger, Zipkin), the health check hits that integration's own well-known endpoint (Prometheus's /-/healthy, Grafana's /api/health, Argo CD's /healthz, Spring's /actuator/health, and so on) over whichever scheme the TLS toggle implies, and falls back to the other scheme if that fails outright: a TCP-level connection succeeding while the actual HTTP exchange fails is usually a scheme mismatch (a service serving HTTPS on a port that doesn't look like it, or vice versa). If both attempts still fail, the reported error is the real underlying one (a timeout, a TLS error, an HTTP status code), not a generic "unreachable", so it's worth reading closely.

Editing an integration

Click Edit on any integration card to change its name, host, port, username, password, or TLS setting without deleting and recreating it. Leave the password field blank to keep the existing one. The integration type can't be changed after creation, since it determines which health check and metrics collector runs for it: delete and re-add it under the correct type instead. Saving re-pings the integration immediately rather than waiting for the next periodic health check (every 30 seconds).

Distributed-tracing integrations (Jaeger, Zipkin) also feed the [Observability](/dashboard/observability) traces view.

Reaching a target on a private network

Integration checks run from KubeWatch's own servers, not from inside your network. On KubeWatch Cloud, that means the host you enter needs to be reachable from the public internet, either directly or through a firewall rule or VPN/peering connection with KubeWatch. A database or VM sitting on a private VPC with no public endpoint can't be reached this way: this feature has no local tunnel or agent to bridge that gap today. On a self-hosted install, this isn't a concern: the integrations service runs as one of your own containers, already inside your network, so anything reachable from that container works, private IPs included.

If pinging an integration fails with a connection timeout rather than a clear error from the target itself (an auth failure, a wrong port), that's usually this: the host is on a network KubeWatch's servers can't route to.