Runs - LumiOps

LUMI · Runbook automation

Runbook automation that executes under policy

Ask LUMI what happened. Approve the fix. LUMI executes the runbook, verifies recovery and writes the record without leaving the channel. It takes the correlated alert, runs the matching runbook against a live model of your estate, and records every action. Irreversible or high blast-radius actions wait for approval.

lumi · run record · orders-db pool exhaustion

Executed under policy

✓CORRELATE3 alerts →one incidentINC-2291

✓MATCHcondition →runbook selectedevidence shown

✓GATEno change window open →approval requiredservice owner

EXECUTEroll back deploy #4471 →scoped, reversiblerunning

●VERIFYp99 inside SLO →close ticketpending

Trigger, actor, actions, result, duration · recorded on every run

85%

of L1 and L2 incidents
resolved autonomously

90%

of routine tasks automated

40–60%

lower operational overhead

Operational outcomes

Operational impact of automated
execution

Automating a documented procedure changes resolution time, escalation volume and
the consistency of the outcome.

Lower MTTR on known failures

Execution starts when the alert fires, not when someone locates the procedure. Lookup, context gathering and coordination time come off the resolution clock.

Less toil, fewer pages

Recurring alerts with a known fix resolve without paging. Only unfamiliar failures reach a human.

Consistent remediation

Identical steps on every run. The outcome no longer depends on who is on call.

Diagnostics collected on trigger

Logs, metrics, traces, topology and recent deploys are gathered and attached to the incident before an engineer opens it.

Expert procedures, safely delegated

Gated runbooks can be invoked by anyone on the rotation without holding the credentials or the context.

Audit trail generated, not written

Trigger, actor, parameters, actions, result and duration for every run. Queryable during the incident and after it.

Execution flow

From correlated alert to verified
recovery

No match means escalation, not improvisation. No open change window means no
execution.

01 · Ingest and correlate

Correlation against the estate model

Alerts from your existing observability tooling are correlated against CERNE’s model of the estate: topology, ownership, dependencies and recent change. Related alerts collapse into one incident.

02 · Select the runbook

Runbook match with supporting evidence

LUMI matches the condition to a runbook and shows the signals behind the match. If nothing matches, the incident escalates to a human.

03 · Check the gate

Policy and change-window evaluation

Policy decides whether the runbook runs unattended, waits for approval or pages. The gate is change aware: execution stops if a deploy or change window is in flight on the same service.

04 · Execute

Bounded, reversible execution

Timeouts, retry limits, scoped credentials and a defined rollback. Restart, scale, fail over, roll back, drain, cordon, purge and reprovision.

05 · Verify and close

Verified recovery and ticket closure

LUMI confirms the alert cleared and the service is inside its objectives, then updates or closes the ticket. On failure it hands over with the full execution context.

Trigger paths

Supported trigger paths

Conversation

Ask LUMI in Teams or Slack. It confirms scope, checks the gate and executes in the same thread.

Alert

The correlated condition fires the workflow directly, with no human in the path for reversible fixes.

Schedule

Maintenance windows, capacity checks, certificate rotation and log rotation on a fixed cadence.

Incident collaboration

Investigation, approval and
execution in a single thread

Incidents are worked in the channel. LUMI works there too: investigating, showing its
evidence, answering the follow-up question and executing once approved. One thread,
start to finish.

slack · #incident-orders-api

Investigate · approve · execute

14:44 first question to 14:54 verified recovery · a single thread and a single record

What teams automate

Automation coverage across eight
operational domains

Start with the highest-frequency procedure you run by hand today, then widen scope on
the execution record.

Domain coverage

01 / 08

Incident remediation

High-signal alerts become auditable remediation flows with health checks before and after.

Service diagnostics, failover and restart with rollback on SLO regression
Database failover: promote secondary, update DNS, verify connectivity
Diagnostic capture on alert to speed root cause analysis

Lower MTTR and a repeatable recovery contract with explicit stop conditions.

02 / 08

Event-driven automation

Standing responses to saturation, drift and hygiene signals across infrastructure and platforms.

Disk and queue cleanup on threshold breach
Scale-out on saturation, then decommission idle instances
Rolling restarts and certificate rotation with smoke tests

Predictable events stop generating tickets and stay inside SLO bands.

03 / 08

Service operations and ITSM

Runbooks bound to ITSM workflows so standard changes carry approvals and evidence.

Standard change: pre-checks, change window, post-validation, CMDB update
Access provisioning and periodic recertification
Zero-touch onboarding and offboarding

Faster fulfilment, fewer exceptions and clean evidence for audit.

04 / 08

Self-service requests

Guarded, policy-driven self-service for frequent tasks that would otherwise queue.

Environment provisioning with tag enforcement and auto-shutdown
Log retrieval with time-bounded access and redaction rules
Just-in-time access with automatic revocation

Routine work shifts to requesters while governance and cost controls hold.

05 / 08

Kubernetes operations

SRE playbooks for deployments, node health and control-plane pressure, with safe rollback.

Canary and blue-green cutovers with instant rollback
Debug state capture on anomaly for post-mortem
Drain, cordon and rebalance with checks either side

Consistent, low-risk changes and faster recovery from cluster incidents.

06 / 08

Data centre and infrastructure

The layer most ITOps automation omits: power, cooling and hardware faults through DCIM.

Power and cooling faults classified, contained and escalated
Power, cooling and floor-space headroom checks that gate deployments
Hardware faults: auto-ticketing, spares dispatch, maintenance windows

Higher uptime and auditable operations at the physical layer.

07 / 08

FinOps automation

Cost signals embedded in operations so waste and anomalies are handled continuously.

Spend spikes, orphaned volumes and idle resources detected and remediated within policy
Weekly rightsizing on top spenders and tag compliance enforcement
Commitment coverage tracked to avoid overcommitment

Cost actions become policy-governed and auditable rather than one-off cleanups.

08 / 08

GreenOps automation

Workloads aligned to energy availability and efficiency targets without compromising SLOs.

Carbon-aware scheduling for batch and training work
Efficiency gates on overprovisioned clusters and non-production hours
Cooling-aware throttling during thermal stress events

Lower energy use and emissions while performance and compliance hold.

What teams automate

Automation coverage across eight
operational domains

Start with the highest-frequency procedure you run by hand today, then widen scope on
the execution record.

Runs inside your boundary

A private model deployed in your environment. Telemetry, configuration, topology and incident history do not leave it, and no execution path depends on a vendor-hosted endpoint.

One model of the estate

LUMI acts on the same model it observes across DCIM, AIOps, HCMP, FinOps and GreenOps. Dependency, owner and last change are known rather than inferred from an alert payload.

Governed autonomy, set per action

Oversight is assigned by reversibility and blast radius. Scope widens on the execution record and narrows when success rates drop.

Conversation and execution in one place

The investigation, the approval and the run happen in the same thread. There is no handoff to a separate automation console in the middle of an incident.

Writes back to the systems of record

The execution record lands in the ticket and the change record without manual copying, so the audit trail is a by-product of the work.

Additive to your stack

Logs, metrics, traces, topology and recent deploys are gathered and attached to the incident before an engineer opens it.

Hybrid and private cloud by design

Colocation, private cloud and public cloud, including the data centre layer, so power, cooling and capacity are part of the incident rather than a separate conversation.

Get started

Start with the procedure you run
most often

Bring a procedure your team currently executes manually. We
will configure it, apply the appropriate gate and walk through the
resulting execution record.

85%

90%

40–60%

Trigger paths

Supported trigger paths

Incident remediation

Event-driven automation

Service operations and ITSM

Self-service requests

Kubernetes operations

Data centre and infrastructure

FinOps automation

GreenOps automation

Build

Orchestrate

Cowork

Resolve

About Us

About Us

Product

Coworker

Orchestrator

Product

Orchestrator

Coworker

Build

Platforms

Estate Models

Agents

Observability

Service Desk