This site is being rebuilt and some pages are out of date. For current details, write to nevio@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

ProductOperate and verify

Incidents and postmortemspreview

Incidents read on the monitor that saw them, with the impact measured.

An incident names the monitors it touched. Its monitor's page draws it over the chart and shows the whole postmortem under it, and the impact beside the text is computed from that monitor's own runs. Every save is a version, a stale save is refused, and only an owner or admin publishes. You acknowledge it from your phone.

Read the docs

Early access: partners get in by request and a signed NDA. No SLA while it lasts.

0%
01Watch it

From the product tour, started at this product's chapter. The narration is an AI voice.

Watch it

InOrbit the engineering platform
Understand your system.
Detect what breaks.
Prove what fixes it.
Monitor, respond, understand and verify, in one loop, with the evidence kept.
01 Monitor live
checkout-api · GET /healthz · every 30 s
13:50p95 per run14:40
PASS 14:01:30 212 ms 200 OK
FAIL 14:02:00 2.9 s 503 from our cloud
FAIL 14:02:00 3.1 s 503 from your agent
Every run becomes evidence.
what was checked
where it ran from
when to the second
what actually happened
example data
02 Respond preview
INC-0142 · CHECKOUT-API
14:02The monitor fails from both places
14:04Opened from the monitor page, responders named
14:05Acknowledged from the lock screen
14:31Resolved
29 min · 4.2% of checks failed · p95 3.4 s
impact measured from 58 monitor runs, not estimated
Today a person opens the incident. Alerts that open it by themselves come next.
14:05
Wednesday 8 October
INORBIT · NOW
INC-0142 · checkout-api failing
Monitor fails from both places
Acknowledge
example data
Every sensor, one evidence model
Direct sensors
HTTP & gRPC monitorslive
Agent checks in your networkpreview
Envoy access logsin dev
Trails browser recordingspreview
eBPF capture, optionalcoming
Read from config
Envoy routesin dev
Kubernetes manifestsin dev
Kubernetes API, read-onlyin dev
Network policiesin dev
Cargo metadatain dev
Read from code
rust-analyzercoming
go/typescoming
TypeScript compilercoming
Java JDTcoming
Python ASTcoming
tree-sitter, the restcoming
Your tools
GitHub pull requestslive
incident.ioin dev
Grafana · Lokicoming
Datadogcoming
PagerDutycoming
Cloud providerscoming
People and models
Reviews of PRDs, ADRs, RFCslive
Acknowledged from the phonepreview
Owner's answerscoming
Docs read by a modelcoming
ONE EVIDENCE MODEL
Every item keeps its method, its source and how it can fail
static resolution · runtime observation · configuration · logs · metrics · traces · external record · testimony · interpretation
Atlas decides what each kind can prove. A model's reading is never proof on its own.
livepreviewin devcoming
real run · 2026-10-08
We tried it on our own platform.
Nobody told it anything. The agent read the system and mapped how it is really built.
0
facts, each linked to its source
0
parts of the system found
0
running services mapped
WHERE THE FACTS CAME FROM
Traffic rules710
Deployment files641
The live cluster385
Code dependencies267
Network rules167
What it worked out by itself:
✓ Which service answers each web address
✓ Which services are allowed to reach the internet
Every fact can be traced back to where it came from. Nothing is a guess.
03 Understand · Atlas in development real topology · example trace
EDGE · ENVOYKUBERNETESNODE · KERNELpackets · connections · DNS · drops · retriesread by the agent's eBPF observer · comingPROCESS · CODEsyscalls · sockets · files · stack samplessame observer, on the process · cominglistener edge :8080Envoy, TLS terminatedroute /v1/* → protocoljwt_authn: iohr-apisvc/protocol :8080EndpointSlice 2/2 readypod protocol-7c9fnode k3d-agent-0veth → conntrack → accept()netns of the podtbd-protocolGET /v1/me handlerengine-lb :50051gRPC, routed by servicepod engine-5d8bnode k3d-agent-11234567
GET /v1/me, traced from the edge to the code and back through the engine load balancer
TRACE · GET /v1/me
1✓envoy.routelistener and route, from the edge config
2✓k8s.manifestthe route's cluster is svc/protocol
3✓k8s.api.read2 of 2 endpoints ready, on agent-0
4?eBPF, optionalkernel path: veth, conntrack, accept()
5✓cargo.metadatacrate tbd-protocol serves the route
6✓configurationprotocol reaches engine via engine-lb
7✓k8s.api.readengine pod, ready, on agent-1
6 of 7 hops proved by 5 methods · hops 4–5 not observed yet
contradictedexit test 2, as specified
Decision: paging makes no calls outside our network
Running system: NetworkPolicy egress-internet-https allows paging and nine other workloads egress to any public host on 443/TCP
Manifest and live cluster agree. Both sides shown; Atlas doesn't pick one.
valid since 2026-10-05recorded 2026-10-08 09:12
the decision is an example
04 Ask your system Atlas · in development example
On a call · 12:04sharing: InOrbit Atlas
SESales engineeryou
CTCustomerCTO
webcheckoutpaymentsledger · down
CUSTOMER ASKS
What breaks for customers if the ledger goes down?
ATLAS ANSWERS, WITH SOURCES
Checkout can't complete payments.
It calls the ledger on every order.
static resolutionruntime observation
ADR-0017 caps retries at 3, so customers see an error in about 2 s.
ADR-0017
Refunds queue and recover later.
k8s.manifest
Not known yet: whether the nightly export needs it.
no observer covers batch jobs
Every answer cites its evidence. What isn't known is said, not guessed.
05 Verify preview real run · 2026-10-04
$ mise run verify:before 251
PASS http_healthz 206.5 ms
PASS grpc_protocol_health 115.0 ms
44 passed, 0 failed
# 39 minutes later, after the change rolled
$ mise run verify:after 251
PASS http_healthz 308.0 ms
FAIL http_mcp_tools 8.3 ms 401 without resource_metadata
43 passed, 1 failed
VERDICT: FAIL
Posted on pull request #251.
Three claims held, one check broke, and the record says so. A verdict only covers what was tested.
06 Install and connect
$ brew install inorbithr/tap/iohr
✓ iohr 0.1.0 installed
$ iohr login
✓ signed in as you@company.example
$ iohr ext install agent
✓ agent enrolled with a one-time code
✓ outbound only · nothing opens inbound
command line · liveagent · previewthe agent is on every plan, Free included
CONNECTIONS · ONLY THE ACCESS EACH ONE NEEDS
GitHublive
Kubernetes, via the agentin dev
incident.ioin dev
Claude, via MCPpreview
Other AI assistants, MCPcoming
Grafanacoming
Lokicoming
Datadogcoming
PagerDutycoming
01Monitorlive
02Respondpreview
03Understandin development
04Verifypreview
EVIDENCE
↺ the evidence feeds the next turn
Every system you run gets its own loop.
InOrbit the engineering platform
Understand your system.
Detect what breaks.
Prove what fixes it.
Request access →inorbit.hrearly access · partners
0:00 / 0:00AI voice Narrated by an AI voice (Bella, ElevenLabs).

Chapters

    Space play or pause · ← → 5 s · 1 to 9 chapters · C captions · F full screen

    Chapter 3 of the tour: Respond · 0:22Watch the whole tourRead the transcript

    02What it does todaypreview

    Each line says how far it is built today. Live means anyone with access uses it; preview means it runs for admins and partners or as a pre-release; coming means it is written down and not built yet.

    What it does today

    • preview

      On the monitor that saw it

      The monitor's page draws the incident as a band over its chart, with the postmortem under it. The Incidents list filters by status, severity, monitor, category and tags.

    • preview

      Impact measured, never typed

      Runs, failed runs and the error rate between start and resolution, computed from the monitors' own runs. A number in the text is the author's; the figures beside it are the platform's.

    • preview

      A postmortem kept like code

      Summary, root cause, timeline, action items with owners and typed evidence links. Every save is a version you can read, compare and restore; a save on a stale version is refused, never merged.

    • preview

      Acknowledged from the phone

      An opened incident pages the phone app; Acknowledge from the incident's page or the lock screen. The timeline names who has it, and the time to acknowledge becomes a figure.

    • coming

      Opened by an alert, shown on a status page

      Incidents that open by themselves when a monitor goes down, review with named reviewers, and your own status page are written down and not built yet.

    03How it works

    The incident is the step between the signal and the record: it starts from a monitor's measurement and ends as a postmortem whose figures anyone can check against the runs.

    How it works

    01Monitor goes downIts runs fail in a row.live
    02Incident opensA person opens it on the monitor; by itself is coming.preview
    03Phone acknowledgesPaged, then acknowledged by name.preview
    04Impact measuredFrom the monitors' own runs.preview
    05Postmortem publishedVersioned; an owner or admin publishes.preview
    From the failed runs to a published postmortem
    04In the consoleExample data

    An incident as the console shows it: the band over the monitor's chart, the measured impact and the timeline with the acknowledgement.

    In the console

    orders-api live

    13:3014:12 · 14:4415:20

    Measured: 31 of 64 runs failed between 14:12 and 14:44, error rate 48%, 32 minutes

    INC-0142 · SEV2 preview

    1. Monitor down: 2 failures in a row
    2. Incident opened on the monitor, SEV2; the phone pages
    3. Acknowledged by Ana, from the lock screen
    4. Roll back of pull request #482
    5. Monitor recovered at the first success
    6. Resolved; postmortem draft, version 3

    Example data

    Drawn from the console's own layout. The services, times and numbers are made up for the example.

    05Proof and links

    Every claim on this page has its evidence: the documents that define it, the docs that say how to use it, and the API it runs on.

    Proof and links

    Documents

    Docs

    API

    • RESTpreviewThe console's routes (list, read, open, save, versions, restore, acknowledge) run for admins and partners. They are not in the public reference yet.
    • Keys and scopescomingincidents:read and incidents:write for keys and tokens open at launch.
    • MCPcomingNot an MCP tool yet: an assistant cannot read or write incidents today.

    The evidence rule: a model saying it succeeded is never evidence. What counts is what was measured, by what, and when.

    Your data, your call

    Evidence is linked by type (a pull request, a run, a record), never pasted log content. Erasing an account erases its incidents, and a person's export includes the incidents that name them.

    Logs record who did what and the outcome, never content. Self-hosted models by default; a third-party model provider needs a data processing agreement before it sees anything of yours. InOrbit is not certified: no auditor has attested its controls yet, and the known gaps are listed.

    The company's facts, controls and gaps →

    06Questions

    Questions, answered plainly

    Does it replace our incident tool?

    For incidents seen by your InOrbit monitors, it can. It does not open incidents from alerts by itself yet, and it has no on-call schedules of its own; incident.io as a connection is in development.

    Who can see and edit a postmortem?

    The account's members read. The owner, an admin or a named responder edits a draft. Only an owner or admin publishes, edits a published postmortem or deletes.

    Can we import the postmortems we already have?

    Records in our Markdown format load unchanged, with every section kept; that is how our own incidents got in. Other formats are not supported yet.

    Why preview?

    It runs in production for admins and partners. Keys, scopes and the public API come at launch, and the page will say live only then.