Skip to main content
Follow one incident from start to finish. You’ll connect a source, watch Rubix investigate, read the RCA, tell Rubix if it got the cause right, assign the Fix and close the incident. The examples come from a demo organization, Acme Payments. A new orders-api version raises its database pool, connections to orders-db run out, and payments-api starts crash-looping in prod-us-east-1. Your names will differ. The steps won’t. You need a RubixKube account. The Individual plan is enough.
1

Connect a source

A source is a Kubernetes cluster, cloud account, machine or tool that RubixKube can see. Click Connect a source in the sidebar, pick what you’re connecting and follow what the dialog shows. Connect your environment has the details.Already connected? Go to the next step.
2

Let an incident open

The observer in your source reports what breaks, and RubixKube turns that into an incident. If you have one open already, use it. If not, you can break something small on purpose:
That image doesn’t exist, so the pod can’t start.
Run this on a test cluster, never on one that serves customers. You’ll delete the pod in step 6.
Open Incidents in the sidebar and wait for it to appear.
Incidents list with an open incident for payments-api crash-loopingIncidents list with an open incident for payments-api crash-looping
3

Watch Rubix investigate

Open the incident. The journey card shows where it is: detected, triaged, waiting, then each part of the investigation with how long it took.
Incident page with the journey card showing Rubix investigatingIncident page with the journey card showing Rubix investigating
The RCA doesn’t always start right away. Critical incidents go first and less serious ones wait longer. While it waits, the card says what it’s waiting for.Curious before it finishes? Click Ask Rubix what it sees so far.
4

Read the RCA

When Rubix finishes, the incident page shows the cause and links to the RCA. You’ll also find it under RCAs in the sidebar.
RCA for the payments-api incident with its impact and root causeRCA for the payments-api incident with its impact and root cause
Start with Root cause and Fix on the Report tab. In our example, the root cause says the new orders-api version used up the orders-db connections, which left payments-api crash-looping. The Fix says to set DB_POOL_SIZE back to 10.Below that you’ll find the Tasks, the impact, the rollback steps and a timeline. The Evidence tab shows what Rubix based its answer on, and Confidence in the side panel shows how sure it is.
5

Say if Rubix got it right

Rubix can be wrong, so every RCA asks. Under the root cause, Was this the cause? has three answers: Right, Partly right and Wrong.
Was this the cause? with Partly right selected and a note saying what it really wasWas this the cause? with Partly right selected and a note saying what it really was
Right is one click. Partly right and Wrong ask what it really was. Rubix reads your note the next time it looks at a problem like this, so a sentence here pays off later.If the RCA missed, you can also pick Run the RCA again from the menu.
6

Assign the Fix

The Tasks section lists what Rubix proposes. A Fix solves this problem. A Follow-up stops it from coming back. Open the Fix.
Task page for the Fix that sets DB_POOL_SIZE back to 10Task page for the Fix that sets DB_POOL_SIZE back to 10
Click Assign to me, or use Assign to… to give it to someone else. Why Rubix suggested it explains the reasoning. Click Start when you begin and Complete when it’s done. If someone should check the work, use Send for review, and they can Approve it.Want help doing it? Ask Rubix about this opens a chat about the Task. What Rubix can do for you there depends on your mode.If you made the test pod, the Fix is to remove it:
7

Say what fixed it

When the problem clears, the observer reports the recovery. If Rubix can’t explain why it recovered, the incident moves to Needs you and asks What fixed it?, or Which of these fixed it? when it saw changes right before the recovery.Pick a change, It recovered on its own or Something else, then click Save answer. Not sure? Ask Rubix to check looks at the evidence for you.A short answer is enough:
If this question doesn’t appear, Rubix doesn’t need the answer. Go to the next step.
8

Close the incident

Open the status menu on the incident and pick Close incident, or press X. It moves to Resolved as closed by you. Open Tasks stay open, so your Follow-ups aren’t lost.If you’d like incidents to close by themselves, turn on Close incidents when they recover in Settings > Incidents.

​
What changes under Observe, Assist and Auto

Modes set how much Rubix can do in a session. The investigation only reads, so it runs the same in every mode. The difference is who makes the change in step 6. Rubix can only change things through the tools you’ve connected. Admins set Mode for new sessions and Highest mode anyone can use in Settings > Modes. Those two apply to the whole organization, and anyone can switch a session’s mode up to that limit with /mode.

​
Common questions

No. An alert marked as known doesn’t get one, and neither does a problem that recovers before the RCA starts. Incidents in a group share one RCA.
An incident is something that broke. An RCA is the report Rubix writes about why, with its evidence and the Tasks it proposes.
The incident page says so and tells you why. Pick Run the RCA again from the menu, or ask Rubix what it can see.
Only in Auto, and only if an admin allows Auto for your organization. Destructive actions still ask.

Incidents

Filters, groups and everything else on the Incidents page.

RCAs

What each part of an RCA tells you.

Modes

Choose how much Rubix can do.

Chat prompts

Good questions to ask Rubix.