About Fortem

Kubernetes has plenty of signals. Operators need a defensible next step.

Fortem comes from years of building operational interfaces around cloud environments. The recurring problem was not a lack of raw data. It was the time spent moving between namespace lists, workload status, pod reasons, events, logs, metrics, and routing just to establish the facts.

The new Fortem focuses on that path. It runs locally, connects through the kubeconfig an engineer already uses, and treats each namespace as an environment in the first release. Its incident brief brings observable facts together, keeps hypotheses explicitly labeled, and links the next check back to the underlying events, logs, resources, or routing.

Local-first is a practical delivery choice. An engineer can use the product without installing a chart or granting a new hosted service access to the cluster. It does not remove the realities of cluster authentication: exec plugins, cloud login, VPN access, credential expiry, and RBAC still apply.

What we believe

Facts before diagnosis.

“Two of three pods are ready” is a fact. “The rollout caused the incident” is a hypothesis. Fortem keeps observations, inferences, confidence, and caveats visually distinct.

Optional data should disappear gracefully, not become a zero. A permission error should identify the missing access. A changing action should say exactly which context, namespace, and object it will affect.

Investigate the cluster you already have.

Install Fortem locally, reproduce the synthetic incident first, then use the same evidence path on one real cluster. No account or in-cluster component required.

or install yourself

Local install · read-only first · no Helm chart