Skip to content
Sencai.docs

Operations overview

Once infrastructure is running, the work shifts from provisioning to keeping it healthy. This section covers that day-2 loop: Operations in the sidebar groups monitoring, incidents, runbooks, and change management into one place, so the path from “something’s wrong” to “it’s fixed and recorded” stays inside the platform.

The loop, in order

Section titled “The loop, in order”
  1. Monitoring collects metrics from your cloud instances and fleet-enrolled agents and evaluates them against alert thresholds.
  2. Incidents groups related alerts into a single, deduplicated record you can triage, with root-cause candidates surfaced alongside it.
  3. Runbooks are the pre-written actions you trigger - manually or as part of remediation - against an enrolled fleet agent, with dry-run and version history.
  4. Auto-remediation lets you turn a recognizable incident pattern into an automatic (or approval-gated) runbook trigger, so the same fix doesn’t need a human every time.
  5. Synthetic monitoring checks your own HTTP endpoints from outside, independent of whether an instance or agent is reporting in.
  6. Deployments tracks what your CI/CD pipeline ships, correlating deploys with the incidents that follow them.
  7. Change requests give risky changes a lightweight draft → review → approved → implemented flow, with a rollback record if needed.
  8. Notifications & escalation is where you control what reaches you and how - in-app, email, webhook, or an on-call chain.

Where each piece lives in the app

Section titled “Where each piece lives in the app”

Most of these live together under the Operations group in the sidebar, but two sit elsewhere - worth knowing so you’re not searching the wrong menu:

PageIn-app path
MonitoringInfrastructure → Monitoring
IncidentsIntelligence → Incidents
RunbooksOperations → Runbooks
Auto-remediationOperations → Auto-Remediation
Synthetic monitoringOperations → Synthetic Monitoring
DeploymentsOperations → Deployments
Change requestsOperations → Change Requests
NotificationsBell icon, plus Settings → Email Notifications / Settings → Escalation

What this section is not

Section titled “What this section is not”

Operations here is about your own infrastructure and workloads. If you manage other organizations’ environments on their behalf, that’s a separate part of the app - also labeled Operations in the sidebar, but as a single top-level dashboard rather than this group of pages - covered in Agency instead.

A concrete example

Section titled “A concrete example”

Disk usage on a provisioned instance crosses a threshold. Monitoring flags it and, once enough related alerts pile up, an Incident is opened automatically. Its context bundle shows a configuration change that landed shortly before disk usage started climbing. You trigger a Runbook that clears disk space on the affected host. Because this is a recognizable pattern, you later create an Auto-remediation rule so the same disk-pressure pattern clears itself next time - with manual review turned on at first, so nothing runs unattended until you trust the pattern. If the underlying fix required a riskier code change, that change would go through a Change request first and show up as a tracked Deployment once shipped. Throughout, you find out what happened via the notification center, email, or however you’ve set up Notifications & escalation.

Who this is for

Section titled “Who this is for”

Most of this section is usable by anyone with the Member role or higher. A few actions are deliberately stricter: creating or triggering a runbook, and creating an auto-remediation rule, both require Admin or Owner - a runbook can restart services or run a script on a real server, so the bar for defining or firing one is higher than for viewing what happened. Auditor and Viewer can read everything in this section (incidents, runbook history, deployment records) without being able to act on it.

What’s next

Section titled “What’s next”