You’re exploring the full DataBridge platform free, with synthetic Future Horizons University data. Everything is unlocked; actions run in your demo session (in-session only, not saved to a real backend).

FHU Databridge
Enterprise
Pricing
6 min

Status & incidents

Publish a public status incident and resolve it.

By the end you’ll be able to

  • Understand what the public status surface communicates.
  • Know the three incident verbs: open, update, resolve.
  • Find the admin surfaces that drive the status feed.

DataBridge ships a public status surface — the `apps/status` mini-app — fed by `@databridge/status-feed`. It communicates the platform's live posture (per-stream submittability, the audit-log chain's validity, cycle deadlines coming due) to customers without requiring them to log in.

A complementary internal signal is `GET /status/badge.svg` (see `docs/OPERATOR_GUIDE.md` §4.4): an embeddable shield badge that is green when the most recent submission per stream is submittable, amber on warnings, and red on overdue cycles or a broken audit chain. It is the right thing to drop into an internal Confluence or SharePoint dashboard.

Incidents are managed through the `databridge status incident` command on the CLI (`apps/cli`). The three verbs are `open` (declare a new incident, optionally with a starting impact level), `update` (post a progress note as the operator works the incident), and `resolve` (close it out). Every verb appends to the same hash-chained audit log the rest of the platform uses — so the incident timeline is provable, not just narrative.

Inside the product the operator works incidents from the admin surfaces. The admin console is the entry; the audit log is where every status change shows up; the waivers, webhooks and marketplace surfaces are where operational follow-ups (suppressing a noisy alert, notifying a downstream consumer, freezing a connector) land. The status badge and the public feed update from the same underlying event stream.

The discipline is: any incident significant enough for a customer to notice gets opened on the public feed, updated as it progresses, and resolved when the platform is healthy again. Silence is not an option — the badge will go red anyway, and a status-feed silence next to a red badge is worse than honest communication.

Walkthrough

  1. 1.Open the admin console

    The admin console is the operator's entry point during an incident.

    Open admin console
  2. 2.Skim the audit log

    Every status change — open, update, resolve — appends to the same hash-chained audit log. That is what makes the incident timeline provable.

    Open audit log
  3. 3.Check the cycle calendar

    Cycle deadlines feed the public status surface: an overdue cycle turns the status badge red. Knowing the next deadline is part of incident triage.

    Open cycle calendar

Your turn

Open the admin console and the audit log. Note that every operator action that drives the status feed is appended to the chain — that is what makes the public timeline provable.

Hint: Use the 'Open the admin console' step above.

Knowledge check

1.Which CLI verbs manage the lifecycle of a public status incident?
2.When does `GET /status/badge.svg` go red?
3.What makes the incident timeline tamper-evident?

Complete this lesson