Skip to the content
OpsCommand
Norsk Book a demo
Menu

How it works

From the first signal to a verified fix.

Eight steps, one record. Each step says plainly whether OpsCommand does it, suggests it, or waits for a person to decide.

Book a demoThe lifecycle

The problem

Fragmented tools. Slower resolution.

Monitoring in one tool, complaints in an inbox, tickets in another system, decisions in chat. Each holds part of the truth; nobody holds the whole picture.

Today: scattered

  • MonitoringA dashboard
  • Customer supportA shared inbox
  • Developer ticketsA ticket queue
  • CommunicationChat threads
  • DeploymentCI logs
  • KnowledgeA wiki

Six places, no single owner

With OpsCommand: one record

INC-1042 · Card payments time out

  • AlertCheckout journey failed three times
  • Customer reportThrough the support widget
  • Developer issueGitHub #412, linked
  • DecisionPosted to Microsoft Teams
  • DeploymentProduction · deploy #2051
  • KnowledgeKnown error, verified

One record, an owner at every step

The OpsCommand approach

  • One operational record.
  • One accountable workflow.
  • One connected team.

Every service, signal, report and fix has its place in one record, with an owner at every step. OpsCommand connects to the tools your teams already use — GitHub, GitLab, Jira, Slack, Microsoft Teams, OpenTelemetry — instead of replacing them.

The lifecycle

Eight steps. Nobody loses the thread.

  • AutomaticOpsCommand does it, and records it.
  • SuggestedProposed with its sources, for a person to weigh. Off until the organisation turns AI on.
  • A person decidesNothing happens until someone with the right role approves.
  1. 01

    Detection

    Automatic

    Checks, heartbeats, alert rules and your services’ own errors raise a signal. Repeats are grouped; a critical alert opens an incident.

    Kept on recordThe first alert, its time and its source

  2. 02

    Investigation

    AutomaticAI can suggest

    Everything related is gathered into the incident: other alerts, customer reports, recent deployments and the service’s dependencies. Similar past incidents are suggested.

    Kept on recordLinked alerts, reports and changes

  3. 03

    Coordination

    Automatic

    The owning team is paged by its escalation policy until someone acknowledges. Customers are told on the status page; the incident has an owner from the first minute.

    Kept on recordWho was paged, who acknowledged, what customers were told

  4. 04

    Developer handover

    A person decidesAI can suggest

    A person hands the fault to development with the evidence attached. AI can draft the handover; a person sends it.

    Kept on recordThe handover, its evidence and its linked issue

  5. 05

    Repair

    A person decides

    Developers fix the cause. Approved recovery procedures run only after a person with the approver’s role says yes, never by the person who asked.

    Kept on recordThe fix, the pull request, every approval

  6. 06

    Deployment

    Automatic

    Your pipeline reports the deployment; OpsCommand links it to the incident it fixes, through GitHub, GitLab or the deployments API.

    Kept on recordThe deployment and the code that went out

  7. 07

    Verification

    Automatic

    The fix counts when the service’s own checks pass in production. A second person can be required to confirm before the incident closes.

    Kept on recordThe checks that passed and who confirmed

  8. 08

    Learning

    A person decidesAI can suggest

    A short review records the cause and the actions. What was learnt becomes a knowledge article and better alerts, so the same fault is caught sooner.

    Kept on recordThe review, its actions and the article

How it works

Inside one incident

Illustration, example data

  1. 01

    Detect early

    Every service is checked from outside, and its own signals are watched. Payments API latency crossed its limit at 13:58; the first customer wrote at 14:09.

    Payments API latency

    2.4 s

    p95 · last 24 h

    Alert at 2 s

    14:40 yesterdayNow

    How detection works

  2. 02

    Coordinate fast

    The owning team is paged, acknowledges and works from one record, and customers are told from the same place. When AI is switched on, it suggests similar incidents with evidence; a person decides.

    1. AlertCheckout check failing
    2. OpenedCritical, from 12 grouped alerts
    3. PagedPlatform team on call
    4. Acknowledged2 min after paging
    5. Customers toldStatus page updated
    How coordination works

  3. 03

    Verify every fix

    The fix is linked to the deploy that made it, and the incident closes only when the service’s own checks pass and a second person confirms.

    1. Fix deployedPR #412 → deploy #2051
    2. Checks passEvery check, checkout included
    3. VerifiedConfirmed by a second person

    Resolved in 1 h 18 min, every step on record

    How verification works

While it happens

One screen for everyone in the room.

The command board brings the incident, its timeline, its impact and its people together.

Illustration, example data

In the product

Incident Management, as it is today.

Incident Management in OpsCommand for an example organisation: the open incidents with their severity, status, service and when each was detected.
Example data, from the product itselfIncident Management, as it is in the product today.

See OpsCommand on your own services.

A 45-minute walkthrough with the people who run your services: one incident, from first alert to verified fix.