On 8 October 2026 Elastic announced the private preview of Elastic nightshift AI SRE, an AI agent built into Elastic Observability that detects and investigates issues and shows its reasoning. It is a sign of where observability tooling is heading: more of the first hour of an incident handled by an assistant that reads your telemetry.
Short answer: Logit.io does not offer an autonomous AI SRE agent. What it offers today is Hosted OpenSearch MCP, a managed, read-only MCP endpoint per stack that lets Cursor or Claude Desktop search your logs, plus a Copy AI prompt in onboarding that lets an assistant add OpenTelemetry to your app without seeing your API key. You stay in charge of the investigation, and the assistant does the querying.
This post covers what each of those does, how to set them up, a worked investigation you can run against your own logs, how to check the assistant's answers, and the limits to keep in mind.
Contents
What Elastic announced
According to Elastic's announcement, nightshift AI SRE continuously evaluates telemetry, tests several root-cause hypotheses in parallel and recommends a fix, with the queries it ran visible to engineers. Elastic says it connects telemetry to source code in GitHub repositories through a knowledge graph and keeps an investigation memory that grows with each resolved incident.
On availability, Elastic says it is in private preview on Elastic Observability Serverless, free for existing Elastic customers during the early access period, with a technical preview planned later in the year and a waitlist for everyone else.
That is a different kind of product from what this post describes. An AI SRE agent decides what to look at. The tools below give your own assistant safe access to your logs, and you decide what to ask.
What Logit.io offers today
| Capability | What it does | Where to find it |
|---|---|---|
| Hosted OpenSearch MCP | A managed, read-only MCP server per stack at {stack-id}-mcp.logit.io, so Cursor or Claude Desktop can list indexes, read mappings, count and search your logs | Stack Settings, Access, then Settings, Endpoints (docs) |
| Copy AI prompt in onboarding | A ready-made prompt that tells an assistant how to add OpenTelemetry to your app and send it to your Logs stack, without including your API key | Onboarding on a Logs stack, OpenTelemetry, then Applications |
| Onboarding that waits for data | After setup, onboarding checks that your first logs are searchable before it moves on | Onboarding on Logs stacks |
| OpenSearch Dashboards | Discover, visualisations and saved searches over the same indexes the assistant queries | Launch from your stack |
None of these run on their own. They are building blocks that make an assistant you already use useful during an incident, and that make the first setup quicker.
How Hosted OpenSearch MCP works
Model Context Protocol (MCP) is a standard way for an AI client to call tools. Logit.io runs the open-source OpenSearch MCP server for each stack you enable, in read-only mode, behind an HTTPS endpoint. The tools it exposes include:
ListIndexToolto list indexes, so the assistant does not invent an index pattern.IndexMappingToolto read field types before writing a query.CountToolto check volume in a time window before pulling documents.SearchIndexToolandMsearchToolfor searches, including several in one call.ClusterHealthTool,GetShardsToolandExplainToolfor cluster state and for understanding why a document matched.
Write tools are not available. The assistant can read your logs but cannot change data, mappings or cluster settings through MCP. MCP has its own username and API key, separate from your OpenSearch API key, and you can rotate it on the Endpoints page.
Hosted OpenSearch MCP is available on Business and Custom plans. It works on Hosted OpenSearch stacks and on Logs stacks running OpenSearch. Logs stacks still on Elasticsearch can't use it. You enable it separately on each stack.
Set up Hosted OpenSearch MCP
Setup takes three steps. Enable OpenSearch MCP under the stack's Settings, Access. Copy the config from Settings, Endpoints into Cursor or Claude Desktop. Then ask the client to list indexes to confirm it connects. The full walkthrough is in Introducing Hosted OpenSearch MCP and the docs. The config has this shape:
{
"mcpServers": {
"logit-opensearch": {
"url": "https://your-stack-id-mcp.logit.io/mcp",
"headers": {
"Authorization": "Basic base64-of-mcp-username:mcp-api-key"
}
}
}
}A worked investigation
Here is a realistic first fifteen minutes after an alert. The service name, fields and times are examples, so swap in your own. For a longer walkthrough of the same approach, see Investigating production logs with Hosted OpenSearch MCP.
Your alert says timeouts on billing-worker rose after a database failover at 14:05 UTC. Start the assistant with the facts you already have, not an open question:
Our database failed over at 2026-10-30T14:05:00Z and billing-worker errors rose afterwards.
1. List indexes that look like application logs.
2. Show the mapping for @timestamp, service.name, log.level and message on the
index you pick, and tell me which are text and which are keyword.
3. Count documents with log.level ERROR for service.name billing-worker in
13:20-14:05 UTC and in 14:05-14:50 UTC, and show both numbers.
Use UTC and an explicit date format on every range filter.A well-behaved client calls ListIndexTool, then IndexMappingTool, then CountTool twice or MsearchTool once. You should see each tool call in the client and can open the query it sent. If the post-failover count is much higher, ask for a sample:
Search the same index for log.level ERROR on billing-worker between
14:05 and 14:50 UTC. Return 20 documents, newest first, with only @timestamp,
host.name and message. Then group the messages into the three most common
error types and count each.This is the point where an assistant saves real time. Grouping twenty timeout and connection errors into three types by hand is slow. The assistant does it in seconds, and the documents are right there for you to check.
Checking the assistant's answer
Treat what the assistant tells you as a lead, not a finding. Before you act on it, run the key count yourself against the OpenSearch API on your stack, using the stack API key from Settings, Endpoints:
curl -s -u "$ES_USER:$ES_API_KEY" -H 'Content-Type: application/json' \
"https://your-stack-id-es.logit.io/logstash-*/_count" -d '{
"query": {"bool": {"filter": [
{"term": {"service.name": "billing-worker"}},
{"term": {"log.level": "ERROR"}},
{"range": {"@timestamp": {"gte": "2026-10-30T14:05:00Z", "lt": "2026-10-30T14:50:00Z",
"format": "strict_date_optional_time"}}}
]}}
}'If your number and the assistant's number match, you can trust the rest of its summary more. If they do not, the usual cause is a field it treated as keyword that is really text, or a different index pattern. You can also open the same query in Discover in OpenSearch Dashboards and look at the documents yourself.
Three checks catch most bad answers:
- Same window, same number. Re-run the count for the exact window the assistant used. A different total means it queried a different index, field or time range.
- Read the query, not just the summary. Ask the client to show the query body it sent. Look for a
termfilter on a text field, a missing time zone or an index pattern wider than you meant. - Spot-check the samples. Open three or four of the documents it quoted in Discover. If the message, host and timestamp match, the grouping built on them is probably sound.
If an answer fails a check, tell the assistant what you found and ask it to redo that step. It will usually correct the query, and the corrected version is worth saving as a starting point for the next incident.
The habits that make MCP answers fast and checkable (a narrow UTC window, the exact service name, counts before documents, mappings before filters) are covered in Investigating production logs with Hosted OpenSearch MCP. One habit worth adding for handovers: close with "Summarise what you found in five bullet points, with the count and time window behind each one."
Getting logs in with an AI prompt
The other half of AI help on Logit.io comes before the incident: getting telemetry flowing. In onboarding on a Logs stack, choose OpenTelemetry, then Applications, and pick your language. Under the setup steps there is a row headed Using an AI assistant? with Copy AI prompt and a Preview button. Instrument with an AI prompt, then check the first data with MCP walks through a full session.
The prompt contains your stack's Hosted OpenTelemetry endpoint and username, but not your API key. It tells the assistant to read the key from the LOGIT_API_KEY environment variable and ask you to set it, so the key stays out of the chat and out of any file the assistant might commit. It also includes the setup that is known to work for that language and rules such as using OTLP over HTTP with http/protobuf, and not adding a second exporter if your app already sends OpenTelemetry somewhere.
Paste it into Cursor or Claude from the root of your app, review the diff, set the key and run the app:
# Linux and macOS
export LOGIT_API_KEY="your-api-key"
# Windows PowerShell
$env:LOGIT_API_KEY = "your-api-key"Onboarding then waits until your first logs are searchable before it moves on. With MCP enabled on the same stack, you can ask the same assistant to count logs from your service.name in the last ten minutes, which closes the loop without leaving the editor.
Failure modes and limits
- Large or slow requests. Very large or slow requests can fail, so narrow the time window, count first and ask for fewer fields.
- No writes. MCP cannot create indexes, change mappings or delete data. Mapping or template changes go through your Logstash pipeline or Logit.io support.
- The assistant can be wrong. It can misread a mapping or summarise documents badly. Check key numbers with your own query before you act.
An AI SRE agent versus an assistant plus MCP
| Question | AI SRE agent (as Elastic describes nightshift) | Your assistant plus Hosted OpenSearch MCP |
|---|---|---|
| Who decides what to look at | The agent evaluates telemetry continuously and chooses what to investigate | You do. The assistant runs the queries you ask for |
| When it runs | All the time, including before an alert fires | When an engineer opens the client and asks |
| Where the data goes | Inside the vendor's observability platform, as Elastic describes it | Search results go from your stack to the AI client and its model provider |
| Cost | Elastic says it is free for existing customers during early access | Your plan, plus whatever your AI client and model cost |
| Control | Reasoning and queries are shown for review | Read-only tools, a separate key you can rotate, and every query visible in the client |
The two approaches answer different needs. An agent that watches everything can catch a problem nobody wrote an alert for. An assistant with read-only MCP is narrower, but you choose the client and model, you can see and repeat every query, and nothing runs unless someone asks it to.
Data handling is the part to think about first. With MCP, the documents the assistant reads leave your stack and go to your AI client and, through it, to the model provider. That is fine for most application logs, but check your policies for logs that hold personal data, and keep secrets out of log lines in the first place.
Cost is easier to predict than it looks. The MCP endpoint comes with your plan, and the model cost depends on how much data the assistant reads. Counting before searching and asking for fewer fields keeps both responses and model usage small.
For many teams the assistant approach is enough. The slow part of an investigation is often writing and rewriting queries, and an assistant with MCP does that well while you keep the judgement.
It also means you can choose your own client and model. MCP is an open protocol, and the server Logit.io hosts is the open-source OpenSearch MCP server, so the same setup works with any client that supports remote MCP over HTTPS with custom headers.
Unlock complete visibility with hosted ELK, Grafana, and Prometheus-backed Observability
Frequently asked questions
Does Logit.io have an AI SRE agent?
No. Logit.io offers Hosted OpenSearch MCP and AI prompts in onboarding. They let an assistant you choose search your logs and set up OpenTelemetry, but they do not investigate on their own.
Which AI clients work with Hosted OpenSearch MCP?
The docs cover Cursor and Claude Desktop. Other clients should work if they support remote MCP over HTTPS with custom headers.
Can the assistant change or delete my data?
No. Hosted OpenSearch MCP is read-only and does not expose write tools. It also uses its own API key, separate from your OpenSearch API key.
Which plans include Hosted OpenSearch MCP?
Hosted OpenSearch MCP is available on Business and Custom plans. It works on Hosted OpenSearch stacks and on Logs stacks running OpenSearch. Logs stacks still on Elasticsearch can't use it. You enable it separately on each stack.
Does the onboarding AI prompt include my API key?
No. It includes your endpoint and username, and tells the assistant to read the key from the LOGIT_API_KEY environment variable that you set yourself.
Do I still need OpenSearch Dashboards?
Yes, for anything visual or shared. MCP is good for questions and quick counts from the editor. Dashboards are better for charts, saved searches and showing the team what happened.
Next steps
Read the Hosted OpenSearch MCP quickstart and the Hosted OpenSearch MCP overview, then enable it on a stack and try the worked investigation above against your own logs.