Welcome to InsightFinder Docs!

ARI: AI SRE

Your AI SRE for Automated Incident Investigation

ARI brings automated incident investigation to InsightFinder. When InsightFinder detects an eligible incident, ARI investigates it using the tools enabled for that system, then saves its analysis and recommended resolution steps on the incident. No one needs to open a chat or submit a prompt to start the investigation.

By taking on the initial work of checking cluster state, reviewing dashboards, and inspecting queues, ARI gives on-call engineers context they can use to assess the problem and decide what to do next.

Automatic investigation. Eligible incidents on enabled systems are picked up by scheduled checks, subject to the investigation policy and available usage quota.

Early insight into potential incidents. InsightFinder’s Incident Prediction identifies warning patterns that may lead to future incidents. ARI provides an assessment and recommended responses to help your team act before service is affected.

Context from your environment. ARI can use GitHub, Kubernetes, Grafana, and RabbitMQ alongside built-in observability and external signals.

Control for your team. Administrators decide which tools are available to each system and can disable access when requirements change.

Code fixes ready for review. When the cause is in your code, ARI can write the fix and open a pull request on a separate branch. Nothing is merged without your team’s review.

One investigation per problem. Related incidents that InsightFinder groups together, and repeats of the same incident, are investigated once rather than once per occurrence.

Findings where you already work. ARI’s report appears on the incident in Problem Investigation as its Action Report, next to the root cause analysis your team already uses.

Approval for sensitive actions. Actions that need consent wait for the system owner to approve them by email.

Anticipate incidents with Incident Prediction

InsightFinder’s Incident Prediction uses patterns learned from the root causes of past incidents to identify early warning signals in incoming data. It predicts which components or instances may be affected and when an incident is expected to occur, helping teams assess potential impact before service is disrupted.

ARI adds an assessment of the predicted incident and recommended responses through the Action Report. Together with the prediction’s timeline, likely causal relationships, and supporting evidence, these findings help engineers understand the risk and decide what to do next.

To view predictions, open Incident Prediction in the left navigation and select a predicted incident. Its details page brings together the AI summary, supporting evidence, and Action Report.

How automated investigation works

ARI checks enabled systems every 10 minutes for eligible metric and log incidents. Each investigation receives the incident context and access to that system’s enabled agents. The resulting findings and recommended resolution steps are saved with the incident.

The workflow covers five stages: incident detection, automatic pickup, investigation, user consent when needed, and saved findings. Engineers review the analysis before deciding how to respond. Automated remediation is separate from the investigation workflow described here.

Step by step

1. Pick up. Every 10 minutes, ARI checks each enabled system for metric and log incidents detected in the last three hours, or since ARI Actions was turned on. The incident action now shows as ‘In Progress’.

2. Check the policy. Each incident is checked against the investigation policy. A repeat, or a related incident that another investigation already covers, is ‘Skipped’. If the organization’s ARI plan or daily token budget does not allow the investigation, it is ‘Denied’.

3. Prepare. ARI gathers the incident details, the organization’s selected ARI model, the system’s enabled agents, and the repositories it may work on.

4. Investigate. An AI coordinator plans the investigation, asks the enabled agents focused questions, weighs their findings, and repeats until it has enough evidence.

5. Ask when needed. If an agent wants to take an action that needs consent, the investigation pauses and the system owner decides by email.

6. Report. The coordinator writes a report in a fixed format, and it is saved on the incident as its Action Report. The status becomes ‘Completed’. An investigation that does not finish is ‘Failed’ and is tried again, up to three attempts in total.

Integrations

Every system includes three built-in agents. These agents require no additional setup and cannot be edited or removed.

Built-in agent	What it contributes
InsightFinder	System health, anomalies, incidents, and root cause analysis from InsightFinder.
Weather Agent	Real-time weather, forecasts, and weather alerts.
Downdetector	Third-party outage reports, including services such as GitHub, AWS, Azure, and Cloudflare.

Connect your own tools

Agent	Required configuration	Supported context or capability
GitHub	Personal access token and repository link	Search repositories; inspect branches and commits; work with pull requests and issues.
Kubernetes	API server URL and service account token	Read pod, deployment, and event state; identify container restarts.
Grafana	Grafana URL and service account token	Run PromQL and LogQL queries; search dashboards; inspect alerts and on-call schedules.
RabbitMQ	Management API URL, username, and password	Read queue depth, consumer counts, and node health.
Custom Agent	Endpoint URL and bearer token	Register and manage an in-house HTTP endpoint and its credentials.

Custom Agent currently supports configuration and management only; custom endpoints are not invoked during investigations. External Model Context Protocol (MCP) servers can also be registered per system, with connection status displayed on the MCP Server tab.

Automated code analysis

When a system has a GitHub agent enabled, ARI’s Code Analysis agent leads the investigation, because a code-level cause needs a code-level fix. Working in its own isolated workspace with the token from your GitHub agent, it:

1. Clones the repository on the branch you chose.

2. Plans the steps for this incident.

3. Analyzes and changes the code: it traces the root cause and writes a fix.

4. Verifies the change where the repository supports it, by building, linting and testing, and tries again if the tests fail.

5. Publishes the fix on a new branch that starts with ari/ and opens a pull request against the branch you chose.

6. Reports the root cause, the evidence, what changed and why, and the pull request link.

The pull request is your checkpoint. ARI never merges or deploys code, and it never pushes directly to protected branches such as main, master, dev, staging or test. When GitHub is not connected, the InsightFinder agent investigates from the system’s observability data.

Choose the branch ARI works on

The GitHub agent’s repository field accepts a comma-separated list of repositories. Add #branch to a repository to set the branch ARI works on, for example: https://github.com/acme/payments#release-2.4

Your choice comes first. A branch set with #branch takes priority over a branch mentioned in the incident.

Default branch otherwise. A repository without #branch uses its default branch. If the branch you set does not exist, ARI uses the default branch.

The right repository. When several repositories are listed, ARI works on the one the incident points to.

Viewing ARI’s findings

For detected incidents

Open Problem Investigation. Every incident has an ARI report column showing the ARI icon and two statuses: Investigation, the status of the incident’s AI summary, and Action, the status of the ARI Action investigation. Hover a status icon to see what it means. Both are described under Investigation status below.

Click the ARI icon to open the incident’s analysis panel; it can be opened once the Investigation or the Action is Completed. When the Action is Completed, the recommendation section of the panel is titled Action Report and shows ARI’s report. Otherwise the section is titled Next Steps and shows InsightFinder’s standard recommended steps. Consolidated incidents show their own statuses in the consolidated incidents drawer.

What the report contains

Every report uses the same headings, so your team always knows where to look.

Heading	Contents
What is broken	The failing component and its visible symptom.
Evidence	What each agent found, with the specific values.
Probable cause	The most likely cause, with a confidence of high, medium or low.
Actions taken	Pull requests, branches and tickets created, with links, or none.
Recommended next action	What the on-call engineer should do next.
Not checked	Anything that could not be investigated, and why.

Reports are kept with the incident for two years.

For predicted incidents

Open Incident Prediction in the left navigation and select a predicted incident. Its details page includes the AI summary, supporting evidence, and Action Report, which presents ARI’s assessment and recommended responses.

You can see the details about Incident Prediction Guide in Incident Prediction.

Security and control

ARI Action scopes integration access to the system being investigated. Administrators manage the tools and credentials made available to that system.

System-specific access. An investigation receives credentials for that system’s enabled agents only. Disabled or removed agents do not contribute credentials to subsequent investigations.

Masked credentials. Saved secrets are not displayed again. Configuration pages indicate that a value is stored, and edit forms show a masked value.

Access that can be paused. Disable an agent to withhold it from subsequent investigations while retaining its configuration. Re-enable it when the tool should be available again.

Separate MCP authentication. MCP connection checks send only the authentication headers configured for that server. InsightFinder does not attach its own credentials to third-party MCP servers.

MCP endpoint restrictions. The MCP connection checker does not contact private, loopback, or internal network addresses. These addresses are reported as blocked.

Restricted administration. Only administrators with the External Service Settings permission and access to the relevant organization can view or change the configuration.

Reviewable code changes. Fixes arrive as pull requests on a separate ari/ branch. ARI never merges, deploys, or pushes to protected branches.

Consent before sensitive actions. Actions that need approval wait for the system owner, through single-use links that expire.

Use read-only credentials where they meet your investigation needs, such as a read-only Kubernetes service account, a Grafana viewer token, and a RabbitMQ monitoring user.

For GitHub, use a token with read and write access to repository contents and pull requests so ARI can open pull requests. A read-only token lets ARI analyze code but not publish a fix.

Who can configure ARI Actions

Role	Configuration scope
Super Admin	Every organization across the platform.
Admin	Their own organization and any other organizations they manage.
Other users	No access to ARI Action configuration.

An organization is a company or tenant on InsightFinder. Authorized administrators can configure systems throughout an organization they can access, including systems owned by colleagues.

Getting started

Open ARI Action Setting under Settings and select the organization and system to configure. Enable investigations, add the relevant agents, and optionally register MCP servers.

Step 1: Enable ARI AI SRE

ARI Actions can be switched on at the system level: Use the System switch to enable or disable investigations for one system.

Step 2: Add agents

On the Agents tab, select Create Agent, choose an agent type, and enter its required configuration fields. The agent name defaults to its type and can be changed to make similar configurations easier to identify.

Rules for adding agents

One enabled agent per type. A system can contain several agents of the same supported type, such as Grafana, but only one can be enabled at a time. Disable the current agent before enabling another.

No duplicate addresses for the same type. A system cannot contain two agents of the same type pointing to the same address.

Custom Agent exception. Several custom agents can be enabled on a system at once. This does not change their current configuration-only status.

Step 3: Register MCP servers

This optional third setup step registers external MCP servers and monitors connectivity. On the MCP Server tab, add each server using the fields below.

Field	Required	Description
Name	No	Defaults to the server’s host name.
URL	Yes	A complete http:// or https:// address. Each address can appear once per system.
Transport	No	HTTP by default, or SSE.
Auth override	No	A flat JSON object of string values sent as request headers, for example {“Authorization”: “Bearer <token>”}.
Env override	No	A flat JSON object of string values.

Each server row displays the authentication type, connection status, and enabled state. Authentication is inferred from the configured key names and may be shown as GitHub App, OAuth 2.0, API token, Custom, or None. Multiple servers can be enabled at once. Disabled servers remain configured but are no longer checked.

A Connected status confirms that the MCP connection check succeeded. Registration and connectivity monitoring do not, by themselves, make a server’s tools available to automated investigations.

Managing agents

Action	Behavior
Edit	Opens the current configuration. Leave masked secret fields unchanged to retain stored credentials, or enter a new value to replace them.
Disable or enable	Keeps the agent configured while controlling whether it is available to investigations.
Delete	Removes the agent and its stored credential, unless another system still uses that credential.

For MCP authentication overrides, resubmitting a masked value keeps the stored value, entering a new value replaces it, and removing a key deletes it. Previously configured GitHub, Kubernetes, Grafana, and RabbitMQ credentials appear automatically as enabled agents. They do not need to be entered again; the first change saves them as regular agents.

MCP connection status

A server is shown as Connected only after a complete MCP handshake succeeds: its address resolves, it answers the initialization request, authentication is accepted, and it returns its tool list. The status may also report how many tools are available.

Checks run immediately after a server is created or edited, and then every 10 minutes. Results are retained for 30 minutes. If a server has not been checked within that period, it is shown as Disconnected rather than displaying an outdated result.

Understand a disconnected status

Reason	What it means and what to check
unreachable	The host name could not be resolved or the connection was refused. Check the address and service availability.
timeout	The server did not respond within the connection check timeout. Check responsiveness and network access.
tls_error	The TLS certificate could not be verified. Check the certificate and trust chain.
auth_rejected	The server rejected the supplied credentials with HTTP 401 or 403. Check the authentication headers and permissions.
server_error	The server returned another non-2xx response. Review the server’s response and logs.
not_an_mcp_server	The endpoint responded but did not complete a valid MCP handshake. Confirm that the URL serves MCP.
invalid_url	The address is not a valid http:// or https:// URL. Correct the URL.
blocked_address	The address points to a private, loopback, or internal network. The connection checker does not contact it.
probe_error	The connection check could not be completed. Review the configuration and retry the check.

Built in guardrails

Enabled systems follow a default investigation policy that governs incident eligibility, duplicate prevention, retries, and usage.

Policy	Default behavior
Incident eligibility	Metric and log incidents detected in the last 30 minutes. Replay projects are excluded.
Duplicate prevention	An incident is claimed before dispatch. Overlapping checks do not start the same in-progress investigation again, and successful investigations are not repeated.
Automatic retries	Failed investigations can be picked up by later checks while still eligible. A recoverable session failure may also receive one immediate retry in a fresh session.
Investigation budget	Up to 20 investigations per system per hour. When the limit is reached, processing pauses for that system. Later processing remains subject to the eligibility window.
Model and usage	Investigations use the organization’s selected ARI model and the same usage metering as ARI chat.
Plan and quota limits	Requests refused by the organization’s ARI plan or quota are marked as skipped and are not retried by later checks.
Related and repeat incidents	Incidents grouped under a main incident, and repeats whose alerts are dampened, are not investigated separately. They are marked skipped and are not charged.
Human approval	Actions that need consent wait up to 25 minutes for the system owner. Unanswered requests are cancelled and noted in the report.
Code changes	Delivered as pull requests on a new ari/ branch. Protected branches are never pushed to.

Related and repeat incidents

A single problem often produces several incidents: the same failure on several instances, a chain of dependent components, or one incident that keeps repeating. ARI follows the same incident grouping and alert dampening that InsightFinder applies to your notifications, so one problem leads to one investigation.

Grouped incidents. When InsightFinder groups related incidents under a main incident, ARI investigates the main incident only. If any incident in the group already has an investigation running or a report saved, the group is not investigated again.

Repeats. When a repeat of an incident falls inside its alert dampening period and its alert is dampened, the repeat is not investigated again. ARI waits up to 10 minutes for this alert decision, then investigates.

Status

Every incident in Problem Investigation shows two statuses next to the ARI icon. Investigation is the incident’s AI summary, which InsightFinder writes for every eligible incident, whether or not ARI AI SRE is turned on. Action is the AI SRE investigation, and has seven statuses. Every incident ends in Completed, Failed, Denied, Skipped or Not Configured.

Action status: the ARI AI SRE investigation

Status	Meaning	What happens next
In Progress	ARI has picked up the incident and is preparing, running or finishing the investigation, including after an approval was decided.	Moves on by itself.
Awaiting Approval	An agent proposed an action that needs consent, and the system owner has been emailed.	Resumes when the owner approves or rejects, or when the 25-minute window ends.
Completed	The investigation finished and its Action Report is saved on the incident.	Final.
Failed	The investigation did not finish this time. A partial report may still be available.	Tried again automatically, up to three attempts, while the incident is within the three-hour window.
Denied	The organization’s ARI plan or daily token budget did not allow the investigation, so nothing ran.	Final. Not charged.
Skipped	The incident repeats, or is grouped under, another incident that is investigated instead.	Checked again while eligible, in case the grouping changes. Not charged.
Not Configured	ARI Action is not set up for this incident: its system is not turned on, its incident type is not investigated, or it happened before ARI Actions turned on.	Nothing. Turn ARI AI SRE on for the system to cover new incidents.

Investigation status: the AI summary

Status	Meaning
In Progress	The summary is queued or being written, including a retry after an earlier attempt failed.
Completed	A summary is ready. It stays Completed even if it is regenerated later.
Failed	The last attempt did not produce a usable summary.
Skipped	The incident was eligible, but no summary was produced for it within the normal processing window.
Not Configured	Summaries are not generated for this incident’s project or system.

Incidents skipped because they repeat, or are grouped under, another incident are also shown as SKIPPED. Unlike plan and quota skips, they are checked again while they remain eligible, in case the grouping changes. Skipped incidents are not charged.

Example configuration

A payments system on Kubernetes

A team runs its production payments service on Kubernetes, uses Grafana for dashboards, and relies on RabbitMQ for messaging. The team connects those tools to give ARI relevant context for incident investigation.

1. Select the system. Open ARI Action Setting and choose prod-payments.

2. Add Kubernetes. Provide the production API server URL and a read-only service account token.

3. Add Grafana. Provide the Grafana URL and a viewer service account token.

4. Add RabbitMQ. Provide the management API URL and credentials for a monitoring user.

5. Enable investigations. Turn on ARI AI SRE for prod-payments.

Eligible incidents can then be investigated with context from cluster state, dashboard metrics, and queue health, using the enabled integrations available in the deployment. If the team no longer wants RabbitMQ included in subsequent investigations, it can disable that agent while retaining its stored configuration.

If the team also connects a GitHub agent for the payments repository, pinned to its release branch, an incident caused by a code change can arrive with a pull request that fixes it. When the same failure shows up on several checkout instances, InsightFinder groups the incidents and ARI investigates them once. The findings and the pull request link appear on the incident in Problem Investigation as its Action Report.

Frequently asked questions

How do I pause ARI Actions? Turn off the System switch for one system, or use the Organization switch to apply the change across all systems. To withhold a single tool from subsequent investigations, disable that agent.

Do I need to re-enter existing credentials? No. Previously configured GitHub, Kubernetes, Grafana, and RabbitMQ credentials appear as enabled agents automatically.

Can MCP connection checks reach private networks? No. The MCP connection checker blocks private, loopback, and internal network addresses. This restriction describes MCP checks; it is not a blanket statement about every infrastructure integration.

How is usage counted? Investigations use the organization’s selected ARI model and ARI chat usage metering. The default investigation budget is 20 per system per hour, and plan and quota limits also apply.

Does investigation begin immediately after detection? ARI checks every 10 minutes. Investigation timing depends on the next check, incident eligibility, and available capacity; completion before an engineer is paged is not guaranteed.

Do Custom Agent and MCP registration enable additional investigation tools? Custom Agent is currently configuration-only. MCP registration verifies connectivity and lists connection status. Neither should be interpreted as automatic invocation of those endpoints during an investigation.

Where do I see what ARI found? In Problem Investigation, the incident’s Action status turns Completed when the investigation has finished. Click the ARI icon: the recommendation section is titled Action Report.

What is the difference between Investigation and Action? Investigation is the incident’s AI summary, written for every eligible incident. Action is the ARI investigation, which runs only on systems where ARI AI SRE is turned on.

Why does an incident show Not Configured? On the Action row, ARI Actions is not turned on for the incident’s system, does not cover its incident type, or was turned on after the incident happened. On the Investigation row, AI summaries are not generated for that project or system.

Does ARI merge or deploy code? No. ARI opens a pull request on a separate ari/ branch. Merging and deploying stay with your team, and protected branches are never pushed to.

Will a burst of related incidents start many investigations? No. Incidents that InsightFinder groups together are investigated once, through the main incident, and dampened repeats are not investigated again. They show as Skipped and are not charged.

Who is asked for approval? The owner of the system the incident belongs to, by email. Unanswered requests expire after 25 minutes.