Find the cause.Restore the service.Prove it recovered.
MonitOps helps IT operations teams find the cause of incidents across the tools they already run, and carry out approved recovery with verified results.
Sample incident console
The sample console follows one simulated incident, INC-20931, at a fictional tenant. The estate starts healthy. Then payments-gw starts failing, and seven alerts from payments-gw, order-api and checkout-web are grouped into one incident with card checkout down. The cause assessment ranks a provider-side fault at payments-gw first and cites the error metric, the timeout log pattern and the provider status page behind it. An operator asks the copilot whether the provider or their own services are at fault, then what changed on order-api, and each answer cites the same evidence. A failover runbook is requested with a note for the approver, approved by a second person and run. Verification checks three recovery criteria, among them the checkout probes and the order-api error rate returning to its baseline, before the incident is resolved. All data is simulated.
Overview
All customer channels · AcmeTraces 6 s behind · topology 12 s agoCustomer channels
Web
Healthycheckout-webApp
Healthymobile-bffContact centre
Healthyivr-gatewaySystems
Customer journeys
Open incidents
No open incidents. Nothing needs you.
Predictions
- Fit
- R² 0.93computed · linear trend, last 3 h · fit quality, not a probability
- 5 % threshold
- in ~1 h 40 min · around 15:40 ICT
- 0 % exhausted
- ~2 h 18 min · around 16:18 ICT
- Predicted alert
- crm-sync-api-quota-low
Recent changes
Last 24 hours
A quiet 24 hours. Four incidents opened and all four resolved; none is open now. The longest was crm-sync latency from 03:10, resolved in 22 min.
When a service breaks, the first hour goes on finding out whose problem it is.
Hundreds of alerts arrive from different monitors. Application, integration and vendor teams each check their own dashboards. A fix gets applied, the command succeeds, and nobody is sure the service actually recovered. MonitOps shortens that hour and makes each step checkable.
- 14:01:58Criticalpayments-gw
- 14:02:03Majororder-api
- 14:02:11Majororder-api
- 14:02:14Majororder-api
- 14:02:16Majorcheckout-web
- 14:02:22Criticalpayments-gw
- 14:02:31Majorcheckout-web
Same 90 s window · shared path checkout-web → order-api → payments-gw
What MonitOps does
Detect and correlate
MonitOps learns the normal shape of every service and journey, and groups the alerts it sees into one incident with the reason they belong together.
How detection worksCard checkout failing at payment authorisation
Same 90 s window · shared path checkout-web → order-api → payments-gw
- payments-gw5xx responsesThreshold · 5xx > 5 %14:01:58
- order-apiUpstream timeoutsLog pattern14:02:03
- order-apiError rateBaseline · p5–p9514:02:11
- order-apip95 latencyBaseline · p5–p9514:02:14
- checkout-webError rateBaseline · p5–p9514:02:16
- payments-gwAvailability probeSynthetic probe14:02:22
- checkout-webCheckout journeySynthetic probe14:02:31
Explain with evidence
Probable causes are ranked with the metrics, logs, changes and topology behind each one. When the evidence is thin, MonitOps says so.
How explanations work- [1]Metricpayments-gw 5xx responses 31 % (baseline under 0.5 %) since 14:01:58
- [2]Logorder-api: upstream timeout calling payments-gw ×1,284 in 4 min
- [3]StatusProvider status page reports degraded card authorisation since 13:59
- [4]TopologyErrors confined to the payments-gw path
Relative confidence ranks candidates against each other. It is not a probability.
Ask in Thai or English
Operators ask what they would ask a colleague. Every answer cites its evidence and respects the asker’s role.
About the copilotผู้ให้บริการชำระเงินมีปัญหาอยู่ไหม?
มีแนวโน้มสูงว่าปัญหาอยู่ที่ผู้ให้บริการ payments-gw ตอบกลับ 5xx 31 % ของคำขอตั้งแต่ 14:01:58 [1] และหน้าสถานะของผู้ให้บริการแจ้งว่าการอนุมัติบัตรขัดข้อง [3] ส่วน order-api ทำงานปกติกับ dependency อื่นทั้งหมด [4]
Answered for Narin S. (operator) · 3 evidence items cited
See limits before you hit them
Forecasts project capacity and quota use forward with an explicit uncertainty band, and raise a predicted-breach alert while there is still time to act.
How prediction workssms-gateway monthly quota crosses 90 % in about 80 min
Restore with authority
Actions come from a catalogue you control, run after the approvals your policy requires, and are checked against fresh service behaviour.
How MonitOps actsVerification
ResolvedRecovery verified against fresh checks, not the command result.
- Synthetic checkout probes
- 20 / 20 passed over 5 min
order-apierror rate- in baseline
- Incident
- Resolved
14:09:52 ICT · run RUN-5521 · approved by Ploy K.
How we think about trust
Evidence before conclusions. Every inference shows what supports it and what is missing.
Your tools, your authority. MonitOps works through the systems and approvals you already have.
Recovery is verified. A successful command is not proof the service is back.
Read how we think about trustSee MonitOps on your own incidents.
We run a working session with your operations team on your services and recent incidents.