Enterprise
Original
Runbooks can't cover everything.
When a pod crashloops at 3am, you need more than pattern matching. You need something that can:
- Investigate across logs, metrics, and configs
- Form hypotheses and test them
- Adapt when the first approach doesn't work
- Explain what it found in plain English
That's what Sabre does.
How Sabre thinks differently
Thinks in steps, not templates
Sabre breaks down complex problems into sub-tasks, investigates each one, and synthesizes the results. When Plan A fails, it tries Plan B — just like your best engineer would.
Runs real analysis, not canned responses
Sabre writes and executes Python code to analyze logs, parse metrics, and compute patterns. It doesn't hallucinate data — it computes it.
# Sabre analyzing pod restart patterns
restarts = kubectl.get_pod_restarts("app=api")
if restarts.last_hour > restarts.daily_avg * 3:
investigate_recent_changes()Inherits your access, not your credentials
Sabre works wherever kubectl works — through bastion hosts, VPNs, service mesh, or zero-trust proxies. It never stores credentials. Your security model stays intact.
Shows its work
Every investigation produces a clear trace: what Sabre checked, what it found, and why it reached its conclusion. Review, learn, and build trust over time.
From question to answer in seconds.
Ask a question
$ sabre "Why is the checkout service timing out?"Sabre investigates
- Checks pod status and recent restarts
- Analyzes logs for errors
- Examines resource usage and limits
- Reviews recent deployments
Get an answer with evidence
The checkout service is timing out because the
database connection pool is exhausted.
Evidence:
47 "connection pool timeout" errors in the last 10 min
DB_POOL_SIZE is set to 5, but 12 replicas are running
This started after the 14:32 deployment that scaled replicas
Suggested fix:
Increase DB_POOL_SIZE to 20 or reduce replica count.Built for the problems that wake you up at night.
Incident Response
Scenario: Pod crashlooping in production
Without Sabre: SSH into bastion, check logs, check events, check configs, check metrics, form hypothesis, repeat.
With Sabre: “Why is the payment pod crashlooping?” → Answer with root cause in 30 seconds.
Performance Investigation
Scenario: Latency spike with no obvious cause
Without Sabre: Manually correlate logs, metrics, and traces across multiple services.
With Sabre: “What's causing latency spikes in the API gateway?” → Sabre traces the request path, identifies the slow dependency.
Configuration Validation
Scenario: Deployment works in staging, fails in prod
Without Sabre: Diff configs manually, check environment variables, compare secrets.
With Sabre: “Why does this deployment work in staging but not prod?” → Sabre diffs and identifies the missing config.
Built for enterprise environments.
Air-gapped ready
Works in disconnected environments. No data leaves your network unless you want it to.
No credential storage
Sabre inherits your kubectl context. Your credentials never touch our servers.
Audit everything
Full execution logs for compliance. See exactly what Sabre did and when.
SOC 2 compliant
Enterprise-grade security for teams that need it.
Frequently asked questions
What models does Sabre use?
Sabre uses GPT-4o by default, with support for other models coming soon. Enterprise customers can bring their own models.
Does Sabre have access to my cluster?
Sabre uses your existing kubectl context. It can only do what you can do. No backdoors, no stored credentials.
Can Sabre make changes to my cluster?
By default, Sabre is read-only. You can enable write operations with explicit confirmation for each action.
How is this different from ChatGPT?
ChatGPT gives generic advice. Sabre actually runs commands against your cluster, analyzes real data, and gives specific answers based on what it finds.
Does it work with EKS/GKE/AKS?
Yes. Sabre works with any Kubernetes cluster that kubectl can reach.
What about air-gapped environments?
Enterprise tier supports fully disconnected deployments with local model hosting.