Automated Incident Response & Remediation
Alerts diagnosed and fixed — automatically.
Incident Copilot handles an incident end-to-end, without waiting on a human to start the work: it gathers the metrics, logs, the code that runs the failing service, and the tickets from the last time this happened; asks Claude, GPT, Gemini, Grok, or your own private endpoint for a root cause and a fix; opens a Slack incident channel; and, wherever your policy allows it, applies the fix itself — scoped, dry-run-tested, and audited. Review sits wherever you choose to put it, not wherever the tool forces it.
Your policy decides what runs itself
Sample incident
Sev1 · InvestigatingHigh error rate on checkout-api
Root cause hypothesis
Database connection pool exhausted — POOL_SIZE is still 5 in app/db.py while active connections have been pinned at the maximum for eleven minutes.
Confidence
High
Fix
Restart pod
checkout-api-7c9f4
✓ Applied automatically under policy restart-on-pool-exhaustion · posted to #inc-1841-checkout-api · OPS-1841
Illustrative. Your dashboard shows your own incidents.
Six stages, one webhook
Everything between an alert firing and an engineer having something to review. The sixth stage is the one most tools skip.
1
An alert fires
Your alerting system posts to a webhook. Grafana Unified Alerting, Alertmanager, or anything that can send JSON — no per-vendor adapter needed.
2
Context is gathered
Metrics, logs and alert rules from your Grafana; the relevant source files from your GitHub or GitLab repository; tickets for the same thing from your Jira, ServiceNow, Linear, or Azure DevOps Boards.
3
Your AI provider reasons over it
One call to whichever AI provider your organisation has configured — Claude, GPT, Gemini, Grok, or a private-hosted endpoint you control — returning structured data: a root-cause hypothesis, an honest confidence rating, and a concrete fix — or an explicit “not enough information”.
4
A fix is drafted
A code fix becomes a draft pull request in your repository. An infrastructure fix becomes a proposed remediation action — reviewed the same way, whether it's dry-run only or a policy allows it to run itself.
5
It lands as a ticket
Root cause, confidence, the proposed fix in full, and links to the draft PR — in the queue your on-call engineer already watches.
6
A human approves
Nothing outside an explicit, narrow policy is applied without someone signing off, and every decision is written to an append-only audit log. Approving records a decision; it does not skip one.
An incident is a coordination problem, not just a diagnosis
A root cause is the start of the work, not the end of it. The rest of the incident happens here too.
Severity, roles, and a status that means something
Every incident gets a severity, an incident commander, and named roles for comms and ops. Status moves through triage → investigating → identified → monitoring → resolved — never a bare “open” ticket nobody owns.
A Slack channel, not a link to one
A dedicated #inc-1841-checkout-api channel is created the moment an incident opens, with a living summary message that updates itself as severity, status, and owners change — so the channel is the incident, not a place people paste updates into.
A postmortem your team actually gets to
Once resolved, a draft postmortem is written from the incident's own timeline and analysis — root cause, impact, what fixed it, a first pass at follow-ups — ready for your team to edit and finish, not a blank template.
A status page that updates itself
Post an update from inside the incident and it reaches your public status page, a token-gated private page, confirmed email subscribers, and your team's own Slack channel — one action, every surface.
A fix that can run itself — on your terms
Most tools in this space stop at a draft PR. Incident Copilot can go further, in three tiers, without needing an agent deployed in every cloud account you run — and never without your explicit policy.
Reachable clusters
For a Kubernetes API server your infrastructure already exposes, Incident Copilot calls it directly — restart a pod, scale a deployment — the same two actions a policy can gate or an approver can run by hand.
CI/CD pipelines
No cluster access needed at all: dispatch a GitHub Actions workflow_dispatch job your own pipeline already defines, and let your existing deploy/rollback tooling do the rest.
Private clusters
For a cluster whose API isn't reachable from the internet, a small satellite agent you deploy runs inside it, polls for approved jobs, and executes with narrowly-scoped in-cluster RBAC — no inbound access to your network, ever.
Need the whole platform running inside your own premises, not just the agent that executes fixes? Incident Copilot can be fully self-hosted — same application, licensed flat rather than metered. Read the deployment guide.
Status pages
Public, scoped, or private
A public status page for the world, sub-pages scoped to one product or region, and a token-gated private page for customers who need the detail the public one doesn't show.
Post an update from the incident
Set component status and publish an update without leaving the incident you're already working — no separate tool, no copy-pasting a summary somewhere else.
Subscribers notified automatically
Every update emails confirmed subscribers and posts to your team's own Slack channel, plus an RSS feed for anyone who'd rather watch than wait for an email.
The part that matters at 3am
A model proposes. Your policy decides.
By default, Incident Copilot has no code path that runs a command against your infrastructure or merges a pull request — it reads, it reasons, and it writes proposals into the tools your team already reviews things in. If you choose to let a narrow, specific action run itself, that choice is yours, written down as a policy, and every run of it is audited exactly like a human approval would be.
- A remediation action only ever runs against a policy your organisation writes. Dry-run by default; auto-execute is something you opt a specific, narrow action into, never a default.
- Code fixes open as draft pull requests — GitHub and GitLab won't merge a draft, and closing one costs a click.
- Every connector credential is encrypted at rest, or lives in your own Vault space; the API returns whether one is configured, never the value.
- Every write this product makes — a draft PR, a ticket, a Slack message, a remediation action — is a connector you opted into, never a default, and always logged.
- Who approved which fix, and when — or which policy let an action run itself — is an append-only audit record, not a mutable column.
How data actually flows
Every hop, in order — including the one step that's your own configuration choice, not ours.
1
Your alert reaches our platform
Posted to a webhook, over HTTPS, into infrastructure Noviqent operates directly — not a third-party cloud subprocessor for this part of the flow.
2
We read from your tools — we don't write to them
Grafana, GitHub, GitLab, Jira, and the rest are read-mostly. The only writes are the ones you explicitly configure: a draft PR, a ticket, a Slack message, a remediation action.
3
Gathered context goes to your AI provider, if you've set one
Claude, GPT, Gemini, Grok, or your own private endpoint — your organisation's choice, using your own key. Nothing is sent anywhere for this step if no provider is configured.
4
A proposal comes back — never an action
Root cause, confidence, and a proposed fix land in your own tools for review. Nothing here has executed anything yet.
5
An approved fix runs one of three ways
From our platform directly against a reachable cloud API, via a GitHub Actions workflow you already own, or via a satellite agent running inside a private cluster you control — see “A fix that can run itself” above.
6
Every credential is isolated from the data it protects
Encrypted at rest in our database, or — if you'd rather we never hold it at all — kept in your own Noviqent Vault space and resolved at the moment it's needed.
Credential storage
Every credential lives in Vault — yours, not ours.
Noviqent Vault is a credential store your organisation controls, separate from this application. Point any connector at a named secret instead of pasting a raw credential in — we resolve it at the moment it's needed and never store the value ourselves. If you'd rather we hold a credential directly, that stays available too: encrypted at rest, never returned by any API response.
Visit Vault →- Your own Vault space, isolated from every other organisation's — not a shared multi-tenant store.
- A secret is referenced by name in a connector's config, never pasted in as plaintext.
- We resolve it at the moment a connector actually needs it — nothing is cached or copied locally.
- Lost access key? A Vault admin reissues one from Vault's own Login methods tab — we never hold it either.
Built to fit into your own compliance program
If your organisation holds SOC 2 or ISO 27001, is pursuing Cyber Essentials, or has UK GDPR or DORA obligations of its own, a vendor like Incident Copilot becomes part of your own audit scope — here's the control-level detail your assessment can check against.
Access control & least privilege
SOC 2 CC6 · ISO 27001 Annex A.9 · NCSC Cloud Security Principle 9
Role-based access per organisation, connector credentials scoped to exactly the read/write pattern each integration needs, and nothing shared across organisations.
Encryption in transit and at rest
SOC 2 CC6 · ISO 27001 Annex A.10 · UK GDPR Art. 32 · NCSC Cloud Security Principles 1 & 5
HTTPS everywhere, credentials encrypted at rest or held in Vault instead, and secrets never returned by any API response — only whether one is configured.
Audit logging
SOC 2 CC7 · ISO 27001 Annex A.12 · Cyber Essentials (Security Update Management)
Every approval, every policy-driven action, and every credential change is written to an append-only audit record — not a mutable column that can be edited after the fact.
Data minimisation & residency
UK GDPR Art. 5 · Art. 44
Your incident data is processed and stored on infrastructure Noviqent operates directly. The one step that leaves that boundary — the AI reasoning call — is your own configuration choice, disclosed in full in our sub-processor register.
Third-party ICT incident support
DORA Art. 28–30 (EU/UK financial entities)
If you're a financial entity subject to DORA, Incident Copilot's own incident record — timeline, root cause, severity, resolution — is exactly the evidence your ICT third-party risk register and incident-reporting obligations need from a vendor.
Basic cyber hygiene
Cyber Essentials
Boundary controls, secure configuration, patch management, and malware protection on the infrastructure this application runs on — the baseline UK government-backed scheme, not a claim of certification (see below).
See the full comparison across every deployment model →
For a full data-processing breakdown see our Privacy Notice and sub-processor register, or email compliance@noviqent.co.uk for a security questionnaire or a Data Processing Agreement.
Connects to what you already run
Each connector is read-only except where it writes a proposal — or an approved action — you asked for. They are your tools; Incident Copilot connects to them, it does not replace them.
Grafana
Metrics, logs, traces, and alert rules — through Grafana's MCP server, so Prometheus, Loki and Tempo all arrive over one connection.
GitHub & GitLab
Reads the source of the failing service, and opens the draft pull or merge request when the fix is a code change.
Jira & friends
Finds the last time this happened, and files the packaged incident where your team already triages work — Jira, ServiceNow, Linear, or Azure DevOps Boards.
Also connects to Slack, Kubernetes (directly or via a satellite agent for private clusters), and SMTP email for status-page notifications.
Stop starting every incident from zero
Connect the tools you already run, point one alert at a webhook, and the next page you get comes with a root cause attached — and a channel, roles, and a status already moving.
Get started