This site is being rebuilt and some pages are out of date. For current details, write to reach@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

← Back to Platform

RFC 0078.1open2026-10-07

One incident in incident.io and InOrbit

With the incident.io connection on, an incident is mirrored both ways and stays one incident.

Part of RFC 0078 A broken monitor explains itself

Problem

A company that runs incident.io coordinates incidents there: the Slack channel, the roles, the updates. InOrbit holds what measured the incident: the monitors, the first report (RFC 0078), the runs, the fixes (RFC 0077). Today the two do not know about each other, so an on-call engineer has two incidents to keep in step, and the phone shows only one of them.

Proposal

When an account turns on the incident.io connection (RFC 0044) and its sync:

  1. Alerts out. A failing monitor's first report goes to the company's InOrbit alert source in incident.io as an alert with a stable deduplication key (RFC 0078); the company's own routes decide whether it becomes an incident.
  2. Incidents in. incident.io's webhooks (incident created, updated, status changed, resolved) are received, verified with their signature, and mirrored as an InOrbit incident linked by the incident.io id: title, severity (SEV1 to SEV4 map one to one), status, timestamps, the Slack channel link and the incident.io URL. The monitors that alerted are attached through the alert's deduplication key.
  3. Changes out. An InOrbit status change, acknowledgement or note on a linked incident is written back through incident.io's API (the connector's update_status and add_note actions, granted on the connection's Access tab), and labelled as coming from InOrbit.
  4. One source of truth per field. Status, severity, roles and the Slack channel follow incident.io; measurements, the first report and fixes follow InOrbit. A conflicting write is refused and shown, never merged silently.
  5. On the phone. A linked incident shows "Coordinated in incident.io" with buttons to open its Slack channel and its incident.io page; acknowledging and status changes go through InOrbit and reach incident.io in the same step.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

Security and compliance

Webhooks are verified before anything is read; the connection's key stays in the vault and only the granted actions run; nothing customer-identifying beyond what incident.io already holds is sent; every sync is audited with who, what and the outcome.

Plan

  1. This RFC.
  2. Incidents in: the webhook receiver, the mirror and the link; the phone shows the link.
  3. Changes out: status, acknowledgement and notes written back.
  4. Alerts out: done in RFC 0078's routes slice.

Status log

  • 2026-10-07: Opened.

This document mentions

Mentioned in

← Back to Platform