Day 2 Ops
After you ship, the real work begins: running, observing, and safely changing systems in production. Exemplar connects automation, events, and AI assistance so Day 2 work is traceable and repeatable—not a pile of ad hoc runbooks.
Definition
Day 2 Ops is the post-launch slice of the SDLC: run, observe, and safely change software already in production—not the initial build and ship. Examples: restart or roll a service after an incident with guardrails and audit trails; grant time-bound access to logs or prod—approved, expiring, and traceable; resize capacity, rotate secrets, or apply a patch outside a big-bang release.
What this solution covers
- Self-service actions — run approved workflows on demand for operational change (private beta).
- Webhooks — reliable inbound and outbound events with signing, retries, and observability (private beta).
- AI co-pilot — platform actions exposed as tools (MCP) in your IDE and assistants.
Examples
Illustrative scenarios—automation, events, and AI for work after launch.
A failed production deploy emits a signed webhook; Exemplar delivers it to your incident channel with retries and delivery logs. The same pipeline can open a ticket or trigger a runbook step—no one-off cron or mystery script.
A service owner runs an approved action: scale read replicas during a traffic spike. Policy requires approval outside business hours; every execution is logged with who ran it, when, and on which service—suitable for audit and retros.
In Cursor or Claude, an engineer asks to list services without recent deploys. MCP tools read the same catalog and activity the dashboard uses—answers stay aligned with production truth, not a stale wiki.
During an incident, temporary access to logs or a narrow prod action is granted with an expiry and approver. Day 2 change stays controlled: access ends automatically; the trail shows why it was opened.
Go deeper on webhooks & event automation and the AI assistant, or open the console.
Open console →