ProductOperate and verify
Monitorslive
Your endpoints, checked on a schedule. Every run kept as evidence.
A monitor runs an endpoint's check every so many seconds, from our cloud or from your own agent, keeps each run for 90 days and sends an event when the target goes down and when it recovers. It is the first sensor of the loop: what it measures is what an incident's impact and a change's verdict are later read from.
Early access: partners get in by request and a signed NDA. No SLA while it lasts.
From the product tour, started at this product's chapter. The narration is an AI voice.
Watch it
Chapters
Space play or pause · ← → 5 s · 1 to 9 chapters · C captions · F full screen
Chapter 2 of the tour: Monitor · 0:08Watch the whole tourRead the transcript
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
- live
Checks on a schedule, from two places
From our cloud for a host inside a domain your account has proved, or from your agent for anything inside your network its local policy allows. HTTP (status, latency, certificate expiry), TCP, TLS and gRPC health.
- live
Every run kept for 90 days
The time, the outcome, the latency, the status code and the class of error. Never a body.
- live
Health you can trust
Down after one to five failures in a row (two unless you say), up at the first success. When the agent running it is offline, the monitor reads unknown: the target was not seen, so it is not called down. Uptime over 24 hours, 7 and 30 days, with p50 and p95 latency.
- live
Down and recovered, as events
monitor.downandmonitor.recovered, ids only, delivered as signed webhooks, over MQTT or as a stream. A missed delivery can be sent again. - live
Category and tags
One category (availability, transport, contract, security, performance, synthetic) and up to ten
key:valuetags. Lists filter by them, and an agent'schecks.tomlsets them for the monitors it declares.
A monitor belongs to a connection, so it inherits the connection's account, where it runs, its credential by reference, its audit and its erasure.
How it works
A monitor's page in the console: the availability strip, latency, the last runs and the incident drawn over the chart.
In the console
orders-api · GET /healthz
every 30 s, from agent-0
- Health
- up
- Uptime 24 h
- 98.92%
- Uptime 30 d
- 99.93%
- Latency p50 · p95
- 42 · 61 ms
Last runs
- 16:42:30pass41 ms200
- 16:42:00pass39 ms200
- 16:41:30pass44 ms200
- 16:41:00pass40 ms200
Example data
Drawn from the console's own layout. The services, times and numbers are made up for the example.
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
API
- RESTliveCreate, list, read, change and delete monitors; read their runs, summary and series.
GET /v1/accounts/orgs/{org_id}/monitors - Eventslive
monitor.downandmonitor.recoveredas webhooks, MQTT or a stream. - SDKs and iohrliveThe same routes from every SDK, and
iohr apifrom the command line. - MCPcomingNot an MCP tool yet: an assistant cannot list or create monitors 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
A monitor keeps timings, status codes and error classes. Never a body, a header value or a secret; a credential stays where it is and is read by reference at the moment of the call.
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.
Questions, answered plainly
Can I monitor something that is not public?
Yes, through your own agent: it runs inside your network and only dials out. Our cloud checks only hosts inside a domain your account has proved is yours.
How often does a check run?
Every so many seconds, as you set it per monitor. Your plan sets the limits; the pricing page says them once it is public.
Who is told when it goes down?
Your systems, through the monitor.down event. When an incident opens, the phone app pages its people (a preview). An incident that opens by itself on monitor.down is not built yet, so today a person opens it from the monitor's page.
Is there an SLA?
No. InOrbit is in early access, and there is no SLA while it lasts.