Priyank Upadhyay
Every team that runs infrastructure has a few people who hold the whole system in their heads.
They know which service talks to which. They know what changed on Tuesday, and who changed it. They know the database slows down at the end of every month because finance runs its reports then, and that the alert which fires every Sunday night is noise. None of this is written down anywhere complete. It lives in a handful of people, and the rest of the team borrows it from them, usually at a bad hour.
That has been the hidden cost of operations for as long as we have had servers. The work is not only fixing things. It is carrying the map. The people who carry it get paged first, get pulled into every incident, and go on holiday with their laptop. When they leave, part of the map leaves with them.
AI changes who carries that map.
It can now read your systems the way those people do. It can look at logs, events, metrics and recent changes, connect what happened in what order, and explain it in plain words. It does not get tired at 3am. It does not forget what it saw last month. It does not mind being asked the same question twice.
That does not make your team less important. It moves their time. Less of it goes to finding out what happened. More of it goes to the decisions that need a person: what to change, what risk to take, what to build so this does not happen again.
We think this is the biggest shift in operations since the move to the cloud. The cloud changed where infrastructure runs. This changes who understands it. And a shift that size calls for a new way of working, and a new kind of tool to work in.
So we rebuilt RubixKube. Not a new coat of paint on the old console. A new console, built from scratch around the two questions that matter most when you run infrastructure:
What needs me?
And what can I do about it?
This post is about why we started over, the ideas we held onto while building, and the small decisions that add up to how it feels to use.
Why we started over
Our old console worked. People signed up, connected their environments with one command, and saw incidents and root cause reports. But it looked and behaved like an infrastructure dashboard from a few years ago. Charts on the home page. Tables of everything. A chat page off to the side.
The product underneath had moved on. RubixKube is now an agent. Observers in your environments, and the tools you already use such as Datadog and PagerDuty, report what breaks. Rubix, our agent, opens an incident, works out why it happened, suggests what to do, and records how it ended. The console was still built for a person who does all of that by hand.
You could see the mismatch in small places. The same thing had three names depending on which page you were on. Three different UI libraries sat side by side, so buttons and menus behaved slightly differently from screen to screen. And the agent, the thing doing most of the work, lived on its own page, as if talking to it were a separate activity from running your systems.
We could have redesigned page by page. We decided not to. When the main idea of a product changes, fixing its screens one at a time keeps the old idea in place. Every page would have been a little better, and the whole would still have said "dashboard".
So we wrote down what the console should be, from the beginning, and built it again. We kept everything that worked: signing up without friction, connecting an environment with one command, incidents, RCAs and tasks, and the same backends and data. We changed how it looks, how you move through it, what things are called, and where Rubix sits.
What needs you
The first question anyone asks when they open an operations tool is not "how are my graphs". It is "is anything wrong, and is it mine?"
So RubixKube opens on that. Home is a conversation with Rubix, and under it is a short list called Rubix noticed: incidents waiting on an answer from you, incidents that opened since you last looked, and what was resolved while you were away.
The incident list is sorted the same way. Not by time, and not by a severity score alone, but by what each incident is waiting for:
- Needs you. Rubix has a question only a person can answer.
- Investigating. Rubix is working on it right now.
- Open. The investigation is done. The cause and the next steps are ready to read.
- Resolved. It is over, and the reason is recorded.
Each row tells you what that incident is waiting on in a few words: a question, an investigation in progress, tasks done, a root cause ready. You can scan forty incidents and know which two you have to think about.
The list stays short for a second reason. Before an incident reaches it, Rubix triages it: it checks the severity, recognizes alerts your team already knows about, and decides how urgently to investigate. When one problem sets off many alerts, from your Observers or from Datadog or PagerDuty, the related incidents become one group with one investigation. A single bad deploy reads as a single problem.
The whole console follows the same split. There are two kinds of screen. A list answers "what needs me?" A page answers "what is going on with this one?" Each has one layout, used everywhere, so once you have learned one list and one page, you have learned them all.
We made one rule early: the story of what happened sits next to the problem. An incident page opens with what happened and the likely cause, in plain sentences. Under it are the tasks that came out of it. Under that is a timeline with what the Observer saw, each step Rubix took while investigating, each status change, and how it ended. While Rubix is still investigating, you watch those steps arrive live: checking pod logs, reading recent deploys, comparing with last week. You never have to open a second tool to find out why the first one is red.
The ending matters as much as the beginning. When an incident closes, it says why: fixed by a change, recovered on its own, resource removed, or closed by a person. An incident that quietly disappears teaches you nothing. One that tells you it recovered on its own three times this month tells you something worth fixing.
What you can do about it
Knowing why something broke is half the job. The other half is deciding what to do, doing it, and making sure it stays done.
Rubix turns what it finds into Tasks. Each one is tagged as a Fix, the thing to do now, or a Follow-up, the thing to do so it does not happen again. A Fix can be a pull request against your code, or a change made through a tool you have connected. Every task links back to the incident it came from, and every one can have an owner. That last part sounds small. It is the difference between a report everyone reads and work someone actually does.
We were careful about one thing above all: nothing changes in your systems until you have allowed it. Rubix can read and investigate on its own. When it wants to change something, it asks. You see what it wants to run, and you approve or deny it from the chat or with a keystroke.
As you come to trust it, you can give it more room. Rubix works in three modes:
- Observe. It reads and investigates. Nothing that writes runs.
- Assist. It can make changes, and every change waits for your approval.
- Auto. It makes changes within the bounds you set, without asking. It still asks before anything destructive.
Admins set the highest mode anyone in the organization may use. People choose within that, per conversation. Hooks let your team add its own checks that run before Rubix changes something, so your rules apply to Rubix the same way they apply to people.
Trust in a colleague is built one decision at a time. We wanted the same to be true here. You start by watching. Then you let it suggest. Then, for the things it has shown it gets right, you let it act. You decide how far it goes, and you can pull it back at any time.
Work with it the way you already work with AI
Most engineers now spend part of every day talking to an AI assistant. They ask it to write a function, explain an error, or review a change. They have learned a way of working: say what you want in plain words, point at the thing you mean, and check what comes back.
We did not want to invent a new way of working for operations. We wanted to use the one people already have. If you have used an AI assistant to write code, you already know how to use RubixKube.
Ask in plain words. "What changed in prod today?" "Why is checkout slow?" "Is anything wrong with the payments environment?" Rubix reads your systems and answers with what it found and how it found it. Every step it takes shows as its own row, so you can see which logs it read and which commands it ran.
Point with @. Type @ and pick an incident, an environment or a service. Rubix now looks at exactly that, instead of guessing what you meant.
Run commands with /. Switch environment, change the model, change the mode, or run one of your team's own commands. Your team writes those once, and everyone can use them.
Teach it with skills. Every team has runbooks: how we roll back, what to check before restarting the queue, who to call when the bank's API is down. Write them as skills, and Rubix uses them when the situation matches. The knowledge that used to live in a few people's heads starts to live somewhere everyone can use.
Keep it next to your work. Rubix is not a separate page. Open any incident, task or environment, and the conversation moves to a panel beside it, already knowing what you are looking at. Close the page and the conversation comes back to the middle.
And you do not have to come to the console at all. Rubix is also in the CLI, in Slack, where each incident gets its own thread, and in the AI tools you already use, like Claude Code, Cursor and VS Code, through MCP. The console is one place to work with Rubix, not the only one.
One word for each thing
Before we drew a single screen, we wrote a list of words: the word we use, and the words we stopped using.
- Environment, not cluster.
- Source, for anything that reports to RubixKube: a cluster, a cloud account, a machine, or a tool like Datadog.
- Incident, not insight.
- RCA, not report, when we mean the RCA.
- Task, a Fix or a Follow-up, not remediation item.
- Organization, not tenant.
- Rubix for the agent, not RubixKube.
This sounds like housekeeping. It is not. When a product calls the same thing by three names, people spend a small amount of attention on every screen asking themselves whether it is the same thing. That attention adds up, and it is taken from the problem they came to solve.
Words also carry ideas. "Cluster" told people we only cared about Kubernetes, when Observers now run on VMs, AWS, GCP and Azure. "Insight" made a production outage sound like a suggestion. "Tenant" is a word from our database, not from our customers. Each of these was a small lie about what the product is.
The same care went into everything the console says. Copy is short and plain. When something fails, the message says what failed and what to do next. It does not say "something went wrong", and it never shows a raw error string.
Calm by design: Paper & Ink
People open an operations tool when something might be wrong. They are already a little stressed. The worst thing a tool can do at that moment is add noise of its own.
Most infrastructure products are loud. Every number has a color, every panel has a border, every chart is animated, and red is used for things that are only slightly unusual. After a week, people stop seeing any of it. When everything shouts, nothing is heard.
We went the other way. The console is quiet until something needs you. Light mode is warm paper with cool ink, not white. Dark mode is a deep blue-grey, not black. There is one blue, and it means one of two things: this is the thing to press, or Rubix is doing this. Green, amber and red are kept for state and never used to make a button stand out. When you see red in RubixKube, it is because something is actually wrong.
A few decisions sit under that.
One source for every value. Every color, size, radius and shadow comes from one file. No component picks its own blue or its own spacing. This is what makes forty screens feel like one product instead of forty, and it is why light mode, dark mode and "follow my system" all work everywhere without anyone having to remember.
Two typefaces, each with a job. Figtree for everything you read, headings included. A second display font would be one more thing to notice. DM Mono only for things you would copy: incident IDs, commands, code. If it is in mono, it is exact and you can paste it somewhere. Numbers in tables stay in Figtree with fixed-width digits, so columns line up without the page looking like a terminal. Three weights do all the work: regular for text, medium for the thing a row is about, semibold for titles. If something needs to stand out more than that, it moves up the page.
Motion only when it tells you something. Things do not slide and bounce for decoration. When an incident arrives while you are looking at the list, its row gets a faint tint that fades over a few seconds, so you notice it without being interrupted. If you scrolled away, a small pill says how many new incidents arrived and takes you up. If your system asks for reduced motion, the console respects it.
The only ornament is made of dots. Behind Home there is a faint glow drawn as an ordered dither, the pattern old printers used to fake a gradient with one ink. The product is about machines, and dots are what machines draw with. It is kept very faint, it never sits behind a table or a form, and it stops if you ask your system for less motion.
Rubix is present, not loud. One mark, a blue bolt, means "Rubix is involved". If you see it, the agent is part of this. If you don't, it isn't. There are no sparkles and no rainbow gradients. Where Rubix did something, its face appears as a small avatar, the same size as a teammate's photo, and it signs its work like a teammate would. It says plainly what it found and how sure it is. It does not interrupt.
Density without clutter. People who run infrastructure look at a lot of rows. We kept rows tight and put the most important thing first. In a task row, that is the priority. In an incident row, it is the severity and what the incident is waiting on. Everything else is one click or one keystroke away.
None of these are features anyone will mention in a review. You notice them after an hour of use, when you realize you are tired less and finding things faster. That is the kind of design we care about most.
Fast, everywhere you are
During an incident, every second you spend finding a button is a second you are not spending on the problem. So we treated speed as part of the design, not something to tune afterwards.
Two keys to anywhere. Press ⌘K to search incidents, RCAs, tasks, environments and past conversations, or to run a command. Press G then a letter to jump: G I for incidents, G E for environments. In any list, J and K move up and down and Enter opens. On an incident, J and K keep going to the next and previous one in the list you came from, so you can work through a queue without going back. Esc goes up one level. ⌘J opens Rubix beside the page. Press ? and every shortcut is listed, and buttons show their key, so you learn them by using the mouse. Single letters only work when nothing is open on top of the page. With a dialog up, typing a C types a C.
Every view is a link. Filters, the open incident and the selected environment live in the URL. When you paste a link to a teammate, they see exactly what you see. That matters most in the middle of an incident, when "look at this" needs to work the first time.
The screen stays current on its own. New incidents, status changes, comments and tasks appear without a refresh. While Rubix investigates an incident, its steps arrive on the page as they happen. When you switch to another tab, the console stops checking until you come back.
It works on your phone. Incidents do not wait until you are at a desk. Below tablet width the console becomes a phone app: a tab bar with Incidents, your tasks and your inbox, and Rubix raised in the middle, one tap away, already knowing what you are looking at. Menus open as sheets you can reach with your thumb. Add it to your home screen and it opens full screen, like any other app.
How we built it
We wrote the spec at the end of September. A little over a week later, the new console replaced the old one at console.rubixkube.ai.
That pace was possible because of a few rules we set on the first day.
Write it down before building it. The spec came first: who the console is for, the list of words, every screen, every shortcut, what each backend already provides and what it does not. The layout was agreed as a mockup before any real code. When a question came up later, the answer was usually already written down, and when it was not, we added it.
Use the tools the way they were meant to be used. We built on well-maintained open source: shadcn for components, TanStack for routing and data, assistant-ui for the conversation. Where one of them already does something, we use it the way its documentation says, and we write our own code only for the glue no library provides. It is less clever. It also means the console keeps getting better as those projects do, and a new engineer can read it on their first day.
Change the surface, not the foundations. The new console talks to the same services and the same data as the old one. Nothing had to be migrated. That let us run both at once and move people over without a big switch.
Use it ourselves, every day. From the first working build, we used it for our own work and fixed whatever got in the way. Many small details came from that. Task rows lead with priority, for example, because that was the first thing we kept looking for.
Nobody is forced to switch. The old console still runs at classic.rubixkube.ai, and each console links to the other. If you depend on something we have not brought over yet, it is still there.
We are not done. Since launch, Automations have arrived: Rubix runs your playbooks on a schedule or when an alert fires, and the investigation behind every RCA now runs as an automation you can open and follow run by run. The new console also made it obvious which parts of the backend need the same care, so that work has started too.
Infrastructure that heals itself, with you deciding how far
For a long time, "self-healing infrastructure" meant a script that restarted a pod when a health check failed. Useful, but narrow. It fixed the symptom it was written for and nothing else, and it never told you why the pod was failing in the first place.
What is possible now is different. An agent that can read your systems, understand what changed, explain it to you, suggest a fix and a way to stop it happening again, and then, when you allow it, make the change and confirm the problem is gone. Not a script for one failure. A colleague that learns how your systems behave.
But a colleague you just met does not get the keys on day one. That is why every part of the new RubixKube is built around trust you can see and control. You see every step Rubix takes. You choose how much it may do on its own. You can teach it your team's way of doing things, and you can take any of it back.
The few people who used to hold the whole system in their heads do not disappear in this picture. They get their evenings back. Their knowledge stops being a single point of failure and becomes something the whole team, and Rubix, can use. And the rest of the team stops having to wait for them to find out what is going on.
That is what we mean by infrastructure that heals itself, with you deciding how far it goes.
The new console is live at console.rubixkube.ai. Sign in and ask Rubix what needs you. If something feels wrong, slow, or missing, tell us. We read every message.
