Docs/Lighthouse discovery

Discovery

When deployed in Kubernetes with discovery enabled, Lighthouse watches Ingresses and Services in the cluster and surfaces them in the dashboard as candidates to monitor. You pick which ones to adopt — adopting creates a real monitor bound to the agent.

Turning it on

Helm:

helm upgrade lighthouse oci://ghcr.io/statusharbor/charts/lighthouse \
  --reuse-values \
  --set discovery.enabled=true

Or set LIGHTHOUSE_DISCOVERY_ENABLED=true and LIGHTHOUSE_DISCOVERY_NAMESPACES=ns-a,ns-b (or *) directly on the agent.

The chart grants the cluster RBAC needed to list/watch Ingresses and Services. If you're running outside the chart, give the agent's service account those verbs across the namespaces you want discovered.

What's discovered

  • Ingresses — host + path + TLS. Show up as candidate HTTP / HTTPS monitors.
  • Services — ClusterIP and LoadBalancer services with at least one TCP/UDP port. Show up as TCP / UDP candidates with the cluster-DNS name (<svc>.<ns>.svc.cluster.local).

Each discovery is keyed by (lighthouse_id, kind, namespace, name, host, path, port, protocol) so re-discoveries don't duplicate.

Adopting

In the dashboard, open the Lighthouse, switch to the Discoveries tab, click Adopt on a row. You can override name, interval, scheme (http↔https) or payload before confirming. A monitor is created bound to the Lighthouse — every new check runs from the agent.

When the underlying resource disappears

If you delete the Ingress / Service that backs an adopted monitor, the discovery row is flagged source missing. The monitor keeps running until you manually delete it — Status Harbor never auto-deletes a monitor on your behalf.

Hiding a discovery

Use the row menu's Hide to keep a discovery out of the active list without deleting it. Hidden rows reappear if you toggle them back.