See, trace, and debug everything your control plane runs. Every read served from an in-memory
cluster cache — ms answers to the questions you ask all day: what's degraded, what composed
what, what actually got created.
✓ No spam — one email when helm install pitbox is real. Nothing else, ever.
Runs in a pod or on a laptop with the UI embedded. No database, no Redis, no sidecars to operate.
XRs, MRs, XRDs, MRDs, Compositions, CompositionRevisions, Providers, Functions, Configurations, Operations, CronOperations, and WatchOperations — understood, not just listed.
Every resource indexed in memory. One palette across names, kinds, and labels at typical cluster sizes.
No drift risk during triage. Mutations aren't registered at all unless you start it with an explicit flag.
01 · Operator experience
Not another CRD table. pitbox understands Composite Resources, compositions, providers, and operations as first-class concepts — and it knows that the hard part of Crossplane isn't listing objects, it's working out why one of them is stuck.
The Overview leads with a diagnosis — what's degraded, the controller's own message, and how long it's been failing. Triage starts at a sentence, not a list.
One palette across every resource in the cluster — names, kinds, labels — with results in under 50 milliseconds at typical cluster sizes.
Walk any XR down through nested composites to every leaf managed resource, with live status at every node. The composition tree, finally legible.
What did this XR actually produce? Wrapped Kubernetes objects, Helm releases, Terraform modules, and
cloud identifiers — flattened into one table with ready-to-paste kubectl commands.
Fan out across the resource, its dependency tree, recent events, and the logs of every pod involved — assembled into a single bounded bundle. No agent, no sampling, nothing running until you ask for it.
That same bundle exports as one self-contained markdown document, sized to paste straight into a chat. Stop screenshotting YAML at your model.
Kubernetes discards events after about an hour — usually right before you go looking. pitbox keeps its own copy for 7 days across every resource it watches, in one filterable feed.
Jump from a degraded XR straight to the provider or function pod that owns it, without hunting for the Deployment. Snapshot by default, live tail on request.
XRs, MRs, XRDs, MRDs, Compositions, CompositionRevisions, Providers, Functions, Configurations, and every Operation kind — live-updating lists and detail pages with YAML, events, and relationships.
02 · Diagnostics
When an XR goes Ready=False, the answer is never in one place. It's split across the
resource, the composed resources beneath it, the events that have probably already expired, and the logs
of whichever provider pod happens to own the thing that broke.
pitbox collects all of it in one pass. Click Investigate and the server fans out across the dependency tree, the event stream, and every pod involved, then returns a single bounded bundle. Nothing runs until you ask — there's no agent, no sampling, and no background collection.
The same bundle exports as one self-contained markdown document, sized to paste directly into a chat. It's the difference between explaining an outage to a model and just handing it the file.
subject XDatabase/prod Ready=False tree 7 composed resources 2 degraded events 23 in the last 6h · past apiserver TTL logs provider-sql 200 lines logs crossplane-core 200 lines environment Crossplane v2.3.1 detected secrets redacted server-side
03 · Compared
Every one of these is answerable with the tools you already have. The point isn't that it's impossible today — it's how many steps sit between the question and the answer.
| The question | Today | With pitbox |
|---|---|---|
| What did this XR actually create? | kubectl get for each kind, then follow resourceRefs by hand, then read annotations for the cloud IDs. |
One table. Every leaf, every external identifier, with the commands pre-built. |
| Why is it degraded? | describe the XR, read conditions, work out which provider owns it, find that pod, logs it, correlate timestamps. |
The diagnosis is the first sentence on the page. |
| What happened an hour ago? | Gone. The API server dropped the events after ~1 hour. | Still there. 7 days, every watched resource, one filterable feed. |
| Which pod do I even look at? | get pods -n crossplane-system and guess from the names. |
One click from the degraded resource to the pod that owns it. |
| Can an LLM help me with this? | Paste YAML. Then events. Then logs. Then explain how they relate. | One bundle, already assembled, already scoped. |
To be fair to the alternatives: kubectl and k9s aren't doing this badly — they're doing it
generically, because they have to work for every workload on Kubernetes. They don't know what a Composition
is, so they can't collapse a composition tree or tell you which provider owns a managed resource. pitbox only works
for Crossplane, which is exactly why it can.
04 · Architecture & operations
pitbox is deliberately boring to operate. There is nothing to scale, nothing to back up, and nothing to page you at 3am.
A single Go binary with the UI embedded. Give it a kubeconfig or run it in-cluster with a ServiceAccount, then open a browser.
Read-only ServiceAccount: get, list, watchList + Watch over every Crossplane kind, held in memory. Cache reads never touch the API server, which is
why answers arrive in ms instead of seconds. Only pod logs and Investigate go to it directly.
Watches stream changes as they happen. Lists update live, and the cache is the only state pitbox has — restart it and it rebuilds in seconds. The one thing that doesn't come back is events the API server has already dropped.
Ephemeral and stateless05 · Roadmap
Everything above works today. Everything below does not — it's listed so you can judge where pitbox is heading before you spend time on it.
OIDC against any provider — Keycloak, Entra ID, Okta, Auth0. Authentication is decoupled from authorization, so the console never needs to know how you logged in.
Kubernetes-shaped roles over Crossplane kinds, scoped by namespace and label — plus deny guardrails that always win. Reads the way your cluster already works.
Annotate, force reconcile, pause, and delete from the console — gated behind those roles, with every mutation attributed to a real person in the audit log.
pitbox already assembles a complete debugging bundle for a model. Next it serves that over MCP, so an agent can ask your control plane what's broken and get a typed answer instead of scraping a terminal.
No dates. This is a small project shipped by people who'd rather under-promise — if a feature matters to you, say so and it moves up.
06 · Questions
The things people ask first, answered as they stand today — not as we hope they'll look at launch.
get, list,
and watch. The mutation service isn't merely hidden in the UI, it isn't registered at all unless you
explicitly start the binary with --enable-writes.v2.3.1. A newer version runs with a warning; an older one is
refused at startup unless you pass --skip-version-check, because pitbox relies on v2 APIs that older
releases don't have. Crossplane v1 is not supported.Launch announcement
pitbox ships as a single binary and a Helm chart at launch. One email when
helm install pitbox is real — nothing else, ever.