OpsCrew

Text Desk is the same helpdesk exposed as an MCP tool surface, so Claude Desktop, Cursor, or whichever AI client your team already lives in can drive it directly.

We scope access by API key to your tenant (the ock_ keys keep each client's data separate). Eight panels do the work: ops_health_check scores a live verdict from services, incidents, and SLA; incident_timeline lays out what happened when; ask_knowledge_base answers with citations and RAG scores; and the intake form files a real ticket and returns a triage verdict.

It renders rich panels in agentUI and clean JSON everywhere else. Pick a surface — the team is the same underneath.

Your monitoring already knows what broke — our Correlator clusters the noise into one incident. It ingests webhooks from Zabbix, Prometheus, ELK, Huawei Cloud Eye, eSight, ManageOne, or plain JSON, then clusters every alert that shares a service and dedupes the rest.

It runs on a cron — every sixty seconds, over a rolling hour — promotes a cluster once it crosses threshold, and auto-resolves the moment every last alert clears.

We kept the cluster key deliberately simple — (tenant, service, window) — deterministic, with no black box, and we can swap it for ML clustering later if you outgrow it.

When the Correlator promotes a cluster, our Incident Analyst writes the brief before anyone is awake: a headline in ninety characters or less, the scope, the timeline, and the one next action — 'roll back v2.41.0, raise pgbouncer ceiling' — then ranked probable causes, each with evidence and a confidence percent.

It opens the Slack war-room, pages through PagerDuty or Opsgenie, and sends a one-click signed ack. When the incident closes, it drafts the post-mortem — blameless.

The outcome we built it for: by the time your on-call engineer sits down, most of that night's work is already done.

The Remediator finds the fix, but we do not let it run the fix. For a firing incident it pulls the SSH runbook commands from your knowledge base and proposes them — your engineer approves before anything touches a host.

Deny-patterns block the destructive commands outright, and every execution is audited, start to finish.

One caveat, stated the way our README states it: point it at real hosts only after you have reviewed the command path. It logs intent; it does not run unsupervised.

We built the Problem Manager to catch the repeat offender. It scans weeks of incident clusters, spots the pattern — 'this gateway flapped five times this month' — then opens a problem record, gives it an owner, and has Claude write a root-cause hypothesis with one concrete permanent fix rather than another restart.

The counting is deterministic — just counts and time windows, nothing you cannot check yourself — and the story on top is written for the person who has to act on it.

The outcome we run it for: the same fault never pages your team twice.

At handover, our Shift Scribe writes the digest the next shift actually reads: one headline, three to six imperative watch items, and the numbers from the shift that just ended.

The digest is markdown — it pastes straight into Slack with no reformatting — and we persist every digest, so nothing falls through the gap between Manila and wherever your next shift sits.

If the API key is missing, it still generates from deterministic rules. The incoming shift inherits a clean board either way.

Our Account Manager writes what lands in your client's inbox on the 1st. One call builds the month-in-review PDF: SLA attainment, ticket volumes, MTTR, incident counts by severity, the problem records, and a recommendations section written from that data only — three to five specific, actionable moves, no filler.

If the API key is missing, the recommendations fall back to deterministic rules and the report still ships on schedule.

We built it because it is the one page your client actually opens — the artefact that shows what the team did for them this month.