Integrations

Most Windows Server installs need WinRM's Basic auth explicitly turned on before this connector can log in (Negotiate, the default, doesn't work with a plain username/password from outside a domain). From an elevated PowerShell prompt on the target:

winrm quickconfig
winrm set winrm/config/service/Auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

Skip the AllowUnencrypted line if you're connecting with TLS on (port 5986) and have a certificate bound to the WinRM listener; leave it in for plain HTTP (port 5985). The Windows Firewall needs to allow the WinRM port either way.

Setting up each SaaS connector

These seven types are SaaS APIs rather than host-reachable services, so each needs its own credential and, for most of them, one or two identifiers beyond that credential. The fields below show up once you pick the type from the catalog.

Netlify

• Personal Access Token, create one from Netlify's User settings → Applications → Personal access tokens.
• Site ID, found on the site's Site settings → General page (labeled "Site ID" or "API ID").

KubeWatch reads the site's most recent deploy, its state, and any build error.

Vercel

• Access token, create one from Vercel's Account Settings → Tokens.
• Project ID, found on the project's Settings → General page.
• Team ID (optional), only needed if the project belongs to a team rather than your personal account, also on Settings → General.

KubeWatch reads the project's most recent deployment, its ready state, and any error.

Cloudflare

• API token, create one from My Profile → API Tokens → Create Token, with Account Analytics read access (avoid the legacy Global API Key, which grants far more than this integration needs).
• Zone ID, found on the zone's Overview page in the Cloudflare dashboard.

KubeWatch reads the zone's requests, bytes served, threats blocked, and cache hit ratio over the last 24 hours.

Snowflake

• Account identifier goes in the Host field, the same identifier you'd use to log in (e.g. xy12345.us-east-1).
• Username goes in the Username field.
• Private key (PEM) goes in the Password field, KubeWatch renders it as a multi-line box for this type specifically, since it's a full PEM block, not a single-line secret. Snowflake's key-pair authentication needs the matching public key registered on the user (ALTER USER <user> SET RSA_PUBLIC_KEY='...'); see Snowflake's key-pair authentication guide if you haven't set this up yet.
• Warehouse, Role, Database, and Schema (all optional) set the session context the query runs under, matching whatever your key-pair user's default role/warehouse can access.

KubeWatch reads total warehouse credit usage over the last 24 hours from SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY, so the role in use needs IMPORTED PRIVILEGES on the SNOWFLAKE database (typically granted via the ACCOUNTADMIN role or a role it's been extended to).

Databricks

• Host is the workspace hostname, e.g. dbc-xxxxxxxx-xxxx.cloud.databricks.com (no https://, no path).
• Password field holds a Personal Access Token, create one from User Settings → Developer → Access tokens.

KubeWatch reads cluster states (how many are running out of the total) and the most recent job run's status and result.

MongoDB Atlas

• Username field holds the Service Account Client ID, created from your Atlas Project's Access Manager → Applications → Service Accounts.
• Password field holds the matching Client Secret.
• Project ID is what Atlas's own UI calls the project, but its API and this field both call it groupId, copy it from the project's Settings page.

KubeWatch reads cluster states and open alert counts.

OpenAI usage tracking

• Password field holds an Admin API key, created from the OpenAI Platform's Organization → Admin keys page. This is a different, higher-privilege key than any completions-scoped key already used elsewhere in KubeWatch for LLM-based log diagnosis, and that key won't work here since it has no permission on the usage/cost endpoints this integration reads.
• Organization ID (optional) is only needed if your OpenAI account belongs to more than one organization.

KubeWatch reads token usage and spend over the last 24 hours.

Adding an integration

1. Click Add integration and pick a type.
2. Fill in the connection fields, typically Host, Port, Username, Password, and a TLS toggle.
3. 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, showing connection info, uptime, and the same live metrics panel shown on its card, at full size.

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, since 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).

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, since 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 because the host is on a network KubeWatch's servers can't route to.