On this page
Quick answer
Every RubixKube RCA ends with Tasks: a Fix for the cause and Follow-ups so it does not happen again. Ask Rubix to make the Fix and it prepares the change in the form your team already reviews, a pull request in GitHub or GitLab or a change through any tool you connect, and waits for your approval.
Nothing changes in Observe. Assist asks before every change. Deleting, scaling and restarting always ask, even in Auto.
Knowing the cause is half the work. The other half is the change, and the review, and making sure it held. RubixKube carries the incident through all three.
From cause to change
- The RCA proposes a Fix. It is a Task with a code such as TSK-52, a priority, and a check that shows whether it worked.
- Ask Rubix to make it. "Open a pull request that sets
DB_POOL_SIZEon orders-api back to 10." Rubix prepares the diff through your connected repository tool. - Approve it. In Assist, an Approval needed card shows exactly what Rubix will do. Approve runs it, Deny stops it, and an approval nobody answers never runs.
- Review and merge as usual. The change goes through your own pipeline, reviews and CI.
- RubixKube checks it held. If the problem comes back within 24 hours of the Fix, the Fix reopens as one that did not hold.
You decide how much Rubix does
Modes
| Mode | What Rubix may do | Good for |
|---|---|---|
| Observe | Read and suggest. It never changes anything | Trying RubixKube on production |
| Assist | Prepare the change and ask before every write | Most teams, most of the time |
| Auto | Make routine changes on its own. Destructive ones still ask | Well-understood fixes in lower environments |
New chats start in Observe, and the highest mode anyone can use is Assist until an admin changes it in Settings > Modes. Allow in this chat saves clicks for one conversation, but never covers a destructive action.
Guardrails your security team will ask about
- Hooks (Business and Enterprise) run before the mode check, and can block a tool or force an approval even in Auto.
- Per-tool switches. Any connected tool's write tools can be turned off one by one.
- An activity log in Settings > Activity records every tool call with its outcome: Ran, Blocked, Needed approval or Failed. Export it as CSV or JSON.
Any tool can carry the change
Connect the tools your team already ships with: GitHub, GitLab, your CI and deploy tools from the integrations catalog, or any MCP server of your own. Their write tools follow your mode, so Rubix opens the pull request or makes the change through them, and asks first in Assist. The same connections let Rubix read commits and pull requests while it investigates, to find the change that caused the incident.
Start free, or read Tasks, Modes and Guardrails.
Frequently asked questions
Will Rubix merge changes on its own?
No. Rubix prepares the change and, in Assist, asks before making it. Review and merge happen in your own pipeline, like any other change.
Can I stop Rubix from writing to a tool?
Yes. Turn off a tool's write tools one by one, keep everyone in Observe or Assist in Settings > Modes, or add a hook that blocks it.
Where can I see everything Rubix did?
Settings > Activity logs every tool call and its outcome, and exports as CSV or JSON.
Do Tasks run by themselves?
No. A Task is a proposal with an owner and a status. It changes something only when someone asks Rubix to carry it out and approves.