For engineering, SRE and IT operations leaders
Shorter incidents, with a person approving every fix
Your incident commander asks Tiersel what is broken and gets the failing service, the deploy that preceded it, the runbook and a status page draft. On-call engineers get the night's alerts grouped into a few real issues. Rollbacks, silences, access grants and postmortems all wait for a named person to approve them.
Live demo on synthetic data · Built on Jev by TypeSafe AI
An animated example types requests as if they were spoken and shows the card Tiersel builds for each one.
For the VP of Engineering, Head of SRE, CIO or IT service management lead
The first twenty minutes of every incident go to finding things.
When a page fires, the responder opens the APM tool, the deploy history, the logs, the runbook wiki and the incident channel, and stitches them together by hand while customers wait. Overnight, one real problem can arrive as dozens of alerts, and the noisy ones train people to ignore pages. Production access requests queue behind a busy approver or get granted too broadly. The postmortem gets written days later from a scrolled-back chat log. Your systems already hold every fact needed. Nobody has time to assemble them while the incident is still open.
4 agent workflows
Built for the work your team already does.
Each workflow starts from a sentence. The agent calls your systems, shows its evidence, and waits for a person before anything consequential happens. Every card below is the real, working interface.
Workflow 01 · Incident commander or primary on-call
Incident command during an outage
01 · Trigger
A service starts failing
An SLO burn alert pages on-call, or the incident commander asks out loud what is going on with checkout.
02 · Tool call
Read errors and traces
Pulls error rate and latency from APM, finds the failing spans and the downstream calls they time out on.
03 · Tool call
Check what changed
Reads deploy history and finds the release that reached the service 14 minutes before errors began, with its diff.
04 · Reasoning
Name the likely cause
Correlates error onset with the new build, maps impacted services and fetches the rollback runbook, with a confidence score and the evidence.
05 · Human approval
Commander approves the rollback
The rollback to the last good version and a status page draft are prepared. Nothing changes in production until the commander approves.
Nothing happens until a person approves06 · Outcome
Mitigated with a record
The rollback runs, the runbook steps are ticked off, and every action lands on the incident timeline for the postmortem.
What changes
The commander starts from the failing service, the suspect deploy and the runbook instead of six browser tabs, and every production change carries an approval.
Workflow 02 · On-call engineer or SRE lead
On-call handoff and alert tuning
01 · Trigger
The shift ends
The outgoing or incoming on-call engineer asks for a summary of the night.
02 · Tool call
Collect alerts and pages
Reads every alert event and page in the window from the monitoring and paging tools, plus the on-call schedule.
03 · Reasoning
Group and find the noise
Groups alerts by fingerprint and service, computes MTTA and MTTR, and flags monitors that flapped without anyone acting on them.
04 · Human approval
Engineer approves the silence
A 24-hour silence for the flapping monitors is prepared with a tuning suggestion. It applies only when the engineer approves.
Nothing happens until a person approves05 · Outcome
A clean handoff
The day shift starts with a short list of real issues and open follow-ups, and the noisy monitors are queued for tuning.
What changes
A night of raw alerts becomes a handful of grouped issues with owners, and monitor tuning starts from evidence instead of complaints.
Workflow 03 · Engineering manager, SRE or security approver
Just-in-time production access
01 · Trigger
An engineer needs production access
A request arrives in chat or by voice for read access to a production database during an investigation.
02 · Tool call
Check identity and ticket
Looks up the requester, their team and manager in the identity provider, and confirms a linked ticket is open and assigned to them.
03 · Tool call
Evaluate policy
Checks least privilege, the time limit, manager approval and recent strong authentication, and finds PII columns to mask.
04 · Reasoning
Score the risk and narrow scope
Scores the request, recommends the narrowest role that fits the ticket, and shows the exact grant as a diff.
05 · Human approval
Approver grants it
A time-boxed grant is prepared with an automatic expiry. Access is created only when the approver says yes.
Nothing happens until a person approves06 · Outcome
Access that expires on its own
The grant revokes itself at the stated time, and the request, policy result and approval are logged to the ticket.
What changes
Production access is granted in minutes at the narrowest scope that fits the ticket, and nothing stays open past its window.
Workflow 04 · Incident owner or engineering manager
Postmortem draft from the incident record
01 · Trigger
The incident is resolved
The incident owner asks for the postmortem draft the day after.
02 · Tool call
Rebuild the timeline
Reads the incident record, the incident channel, deploy diffs and service metrics to build a timestamped timeline.
03 · Tool call
Measure the impact
Counts failed requests and affected customers and reads how much error budget the incident used.
04 · Reasoning
Draft cause and actions
Writes the summary, root cause and contributing factors in blameless language, and proposes action items with owners and due dates.
05 · Human approval
Owner reviews and publishes
The owner edits the draft, picks which action items become tickets, and approves publishing.
Nothing happens until a person approves06 · Outcome
Actions tracked, not forgotten
The review is posted to the incident review channel and each approved action item becomes a ticket with an owner.
What changes
The postmortem is drafted while the details are fresh, and its action items land in the backlog with owners instead of in a document nobody reopens.
How it plugs in
An agent on your systems, one component per workflow.
Requests come in by voice, text or system event. The router picks the workflow, the agent calls your systems, and the answer lands as a live card where your team works. Nothing is written back until a person approves it.
In
Tiersel
Your systems
Out
Workflow blueprint · Incident commander or primary on-call
Incident command during an outage
- Starts when
- A service starts failing. An SLO burn alert pages on-call, or the incident commander asks out loud what is going on with checkout.
- Reads
- Read errors and traces. Pulls error rate and latency from APM, finds the failing spans and the downstream calls they time out on.
- Check what changed. Reads deploy history and finds the release that reached the service 14 minutes before errors began, with its diff.
- Decides
- Name the likely cause. Correlates error onset with the new build, maps impacted services and fetches the rollback runbook, with a confidence score and the evidence.
- Waits for
- Commander approves the rollback. The rollback to the last good version and a status page draft are prepared. Nothing changes in production until the commander approves.
- Writes back
- Mitigated with a record. The rollback runs, the runbook steps are ticked off, and every action lands on the incident timeline for the postmortem.
This workflow is one component
export const incident = defineSkill({id: "incident", category: "ops",// when this workflow, and not a neighbour, is meantcriterion: "An engineer or incident commander asks about a live production incident or outage: what is failing, the likely cause, impacted services, the runbook, a status page update or a rollback. Not a past incident's postmortem, not overnight alert summaries, and not a home or insurance incident.",examples: ["what's going on with the checkout outage", "why is the payments api throwing errors"],match: (text) => score, // intent score, runs on every wordparse: (text, ctx) => record, // entities + tool calls into your systemsreply: (record) => "…",Card: IncidentCommandCard, // the live UI, with its approval step});
The id, criterion, examples and reply are read live from the skill that renders the card above. Adding a workflow for your team means adding one of these: its intent, the calls it makes, what it says, and the interface your people approve in.
Fits your stack, answers to your people
Reads your systems. Acts only with approval.
What the agent connects to
Observability and APM
Paging and incident management
CI/CD and deploys
ITSM and ticketing
Identity and access
Chat and status page
Product names are examples of systems in this category. Each deployment is connected to your systems through their APIs as part of the build.
A person approves every production change
Rollbacks, alert silences, access grants and published postmortems are prepared by the agent and carried out only after a named person approves them.
Every step is logged
Each tool call, the evidence it returned and the approval or rejection are written to the incident or ticket, so anyone can replay how a decision was made.
Synthetic data in this demo
Every service, engineer, incident and number on this page is invented, so nothing you try here touches a real system.
Least privilege, in your environment
When deployed, Tiersel acts only through the scoped, read-first credentials you grant, and logs and customer data stay in your environment.
The cost of doing it by hand
Put your own numbers in.
Move the sliders to match your operation. Nothing is sent anywhere unless you choose to email it.
Each year
672
staff hours back, about 0.3 full-time people
$67,200
of staff time, at your hourly cost
Email me a pilot plan for these numbersCounts only engineer time spent gathering context, posting updates, building the timeline and writing the postmortem, summed across responders. It excludes the cost of downtime itself and assumes no change in incident count. The hourly default starts from the BLS mean wage for software developers, $71.20 in May 2025, plus about 40 percent for benefits and overhead.
Hours = incidents a month × 12 × minutes each × share, ÷ 60. A full-time person is 2,080 hours a year. Default hourly cost from U.S. Bureau of Labor Statistics, OEWS May 2025, software developers, 2026.
Questions buyers ask
Straight answers.
No. Tiersel sits on top of the tools you already run. When deployed, it reads from them and writes back through their APIs with the permissions you grant. The demo on this page uses synthetic data and connects to nothing.
No. It prepares the rollback, silence, grant or publish step and shows the evidence. Nothing changes until a person approves it, and the approval is logged with the incident or ticket.
It lines up error onset with recent deploys, config changes and failing traces, and shows each piece of evidence with a confidence score. It points the commander at the likely cause. The commander still decides.
A pilot starts read-only: metrics, deploy history, alerts and the incident record. Write actions such as rollbacks or access grants are added one at a time, each scoped to the smallest role that does the job.
When deployed, they stay in your environment, and each tool call asks only for the fields the workflow needs. In this demo there is no real data at all.
Try the live demo on this page now. A pilot starts with one team, one service and the on-call summary, read-only, so your engineers can compare it with their own handoff before anything writes back.
See it on your own workflow.
Watch the it operations workflows run end to end, or speak to the agent yourself. Then tell us which one to build on your data.
Scope a pilot with hello@sasid.ai- 01
Pick one workflow
A short call to choose the workflow that costs you the most time, and who approves its actions.
- 02
See it on your data
We build that workflow against your sample or de-identified data so your team judges the real thing.
- 03
Run it with people in charge
Your staff use it on live work. The agent drafts and prepares; a person approves every consequential step.
- 04
Decide from results
You keep what measurably saves time and drop what does not.
Other operations
The same agent, other teams.
- Contact centers and customer operationsScore and coach every call, not one percentLive assist on a billing callQA on every callQueue pulse and staffing movesCustomer lookup with a next best action
- Healthcare providersTake the desk work off your cliniciansPre-visit chart reviewReferral and specialist bookingResults inbox triagePrior authorization packet
- Banks, credit unions and fintechsWork the alert queue with every step loggedFraud alert reviewKYC and KYB onboarding reviewClient book rebalancingLoan underwriting
- Property and casualty insuranceEvery new claim triaged before adjusters log inFirst notice of loss to an assigned claimMorning triage of new claimsCoverage position on a reported lossCommercial renewal review
- B2B SaaS revenue teamsKnow which deals slip before the forecast callAccount brief before a customer callPipeline review for the quarterChurn risk and save playsDeal desk discount approval
- Logistics and supply chainFix freight exceptions before customers feel themShipment exception recoveryStockout risk and rebalancingLoad dispatchSupplier scorecard and corrective action
- Restaurants and restaurant groupsCatch every leak before the next serviceLoss watch on the registerOwner brief after closeCover a call-out86 an item everywhereUnstick the kitchenKeep the pickup shelf moving