Watch the video
The InOrbit tour
A short narrated tour of InOrbit: monitor, respond, understand with Atlas, verify, and how to get started.
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
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
SESales engineeryou
CTCustomerCTO
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 [email protected]
$ 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:00Narration plays at 1×AI voice Narrated by an AI voice (Bella, ElevenLabs).
Chapters
Space play or pause · ← → 5 s · 1 to 9 chapters · C captions · F full screen
Narrated by an AI voice (Bella, from ElevenLabs). The script was written for InOrbit and approved by Nevio Vesić (owner) on 2026-10-08.