Why we are building Orbit
Five disconnected tools slow every team down. The problem we saw, the connected loop from work item to postmortem, and an honest account of what is built.
Most software teams run on five tools that do not know about each other. Work is tracked in one place, code lives in another, builds run in a third, production is watched in a fourth, and the knowledge of how it all fits together sits in a wiki that nobody trusts. Each tool is good at its own job. The trouble is everything between them.
We are building Orbit to remove that gap. This post explains the problem, what we are making instead, and where the work honestly stands today. Orbit is pre-launch: it is in private preview, nothing is sold yet, and this post will tell you which parts are built and which are not.
The problem: five tools, many seamsLink to section: The problem: five tools, many seams
Picture an ordinary incident. A monitor fires. Someone opens the observability tool, finds an error, and copies its stack trace into the work tracker. Somebody else asks which deploy caused it, so they open the code host and read the commit list. Later, a person writes a postmortem in the wiki and copies action items back into the tracker by hand. At every step a human carries information from one tool to the next, and each hand-off loses a little: a link, a version, the reason a decision was made.
The seams cost more than time. Each tool has its own accounts, its own roles and its own idea of who may see what. When someone leaves a project you remove them in five places and hope you found them all. When a new colleague joins, they need five invitations. Permissions drift apart, and nobody can answer a simple question like “who can read this team’s production logs?” without opening several admin screens.
Search suffers too. The answer to “why did we change that timeout?” is spread across a work item, a merge request, a dashboard annotation and a runbook. No single search covers all four, so people ask in chat and the answer lives in a thread that disappears.
The loop we wantLink to section: The loop we want
Orbit is one platform made of five products, built to close that loop from the first idea to the last lesson learned:
- Orbit tracks and plans the work: projects, work items, boards, backlog, sprints, workflows, search and reports.
- Orbit Forge hosts the code and runs delivery: merge requests, CI/CD pipelines, runners, environments and deployments.
- Orbit Pulse watches production: logs, traces, metrics, errors, monitors, SLOs and incidents.
- Orbit Folio keeps the knowledge: spaces, pages, runbooks and postmortems.
- Orbit Lumen is an assistant across all four that answers with sources.
The point is not that there are five products. The point is the chain between them. A work item links to its branches, merge requests and deployments. Pulse records every Forge deployment and compares error rate and latency before and after it. An error or a monitor can file an Orbit bug, one per problem, and keep it in sync. An incident turns into a postmortem page in Folio whose follow-up actions are Orbit tasks. And Lumen can answer “what broke?” with the deploy, its commits, the related work and the runbook in one cited answer.
That is the connected loop: from a work item, through code and delivery, into production, and back into knowledge and new work. Nothing in it needs a person to copy a link from one window to another.
One sign-in, one permission modelLink to section: One sign-in, one permission model
The second idea is as important as the first. Forge, Pulse, Folio and Lumen use the same Orbit session and check the person’s current project role on every request. There is one people directory, one place to decide who may open each product, and one audit log. Lumen reads other products only through their own APIs, as the person who asked, so it can never show someone something they could not open themselves.
Each company works on its own address, <company>.orbit.inortix.com, and its data is isolated at the database level with row-level security. Storage is one quota per organization, shared by all products, rather than a separate allowance for each tool.
What is built, and what is notLink to section: What is built, and what is not
We would rather be plain about this than impressive. The pages on this site mark every capability as built, In development or Planned, and we use the same rule here.
Built today (no badge on the product pages): boards, backlog and sprints in Orbit; a typed JQL-style search; Forge merge requests and .gitlab-ci.yml-compatible pipelines on your own runners; Pulse intake over OpenTelemetry for logs, traces and metrics, with monitors, SLOs and incidents; Folio spaces, pages, versions and postmortems; and Lumen answers with sources, with “Find everywhere” search that needs no model at all.
In development: Jira Cloud import is in final testing, as are automation rules and outgoing webhooks. SAML, SCIM and enforced single sign-on for organizations are being finished. Lumen answering on Orbit’s cloud with Claude Haiku 5.5 is in final testing, and so is a read-only MCP server that lets coding agents such as Claude Code read your work items, merge requests and pages. “Find everywhere” search works without any model.
Planned: shared CI runners with included minutes, so Forge works without your own runners. Separate data per organization for Forge, Pulse, Folio and Lumen, which we treat as a launch condition. Service management, an Orbit MCP server for external agents, monitoring for your own databases in Pulse, and a self-hosted licence for Enterprise customers.
The full list, with next and later items, is on the roadmap. We do not give dates there, because we do not want to promise what we cannot yet keep.
Why not just integrate the tools we have?Link to section: Why not just integrate the tools we have?
We considered it. Integrations are useful, and Orbit ships them: GitHub and GitLab development information is in development, and the REST API is documented. But an integration moves data between tools that still disagree about identity, permissions and structure. It cannot make “who may see this?” a single answer, and it cannot make a deployment a first-class thing that a work item, an error and a postmortem all point to.
Building the products together lets us decide those questions once. The cost is obvious: it is a lot of work, and it only pays off if each product is good enough on its own. That is why each one has to stand up to its own scrutiny, with compatibility where it helps people move: a JQL subset with history predicates, a Jira Cloud export import, .gitlab-ci.yml pipelines, and standard OpenTelemetry for telemetry.
Honest statusLink to section: Honest status
Orbit is in private preview. There are no customers to quote, no usage figures to show and no uptime record to point to, and we will not make any up. What we can show is the product and a clear account of what is finished. The pricing page describes the catalogue planned for launch (Free, Team and Business per user per month, and Enterprise by contract), and says plainly that it may change before launch. Every new organization will start with a Business-plan trial, no card required, once sign-up opens.
If this is the kind of platform you want to use, the best way to follow it is to read the documentation, watch the roadmap, and come back to this blog. We plan to write here about how the pieces are built, starting with how Pulse stores telemetry. We will say what works, what does not yet, and what we changed our minds about.