Introducing CtrlB AI Insight Engine, built for failures your alerts may miss
Log search is useful when you know what you are looking for. The problem starts when you do not. Even with months of logs in a data lake, every search begins with an engineer deciding what to query.
Alerts have a similar limitation: someone has to define the condition first. A failure that does not match an existing alert can sit in the logs unnoticed. An engineer may only start looking after a customer reports a problem, then work backward to find when it began.
We built the AI Insight Engine to look for these problems before an engineer has to search for them. It reads your logs as they arrive, groups repeated messages into patterns, and ranks those patterns by severity and impact. Each insight includes the matching evidence and a hypothesis to check.
From raw logs to an insight
The engine works on logs while CtrlB is ingesting them, across the datasets and time range you select. Repeated messages collapse into patterns. A warning that fires all afternoon becomes one pattern with its count. The engine also flags behavior that breaks from the usual.
Every pattern is labelled Critical, High, Medium or Low. An impact score shows how much of the system the pattern could affect. Each finding also carries its dataset and a category such as network, database or resource exhaustion. No query or threshold is required.
The engine reads the logs you ship rather than a sample. A pattern in a low-traffic service can surface alongside one from checkout. Point it at several datasets and the engine ranks findings across them together.
Six things it does with your logs
• Detection that starts without a query
Search answers the question you bring to it. The Insight Engine starts from the logs instead, looking across the selected window for patterns and anomalies. A checkout service might log "connection pool exhausted" a few times an hour for a week without triggering an alert. Finding that pattern before a customer report can reduce MTTD.
• The matching logs sit next to the claim
Each insight includes a summary of the behavior and the logs that matched it. The sample size and activity timeline stay alongside the finding, so an engineer can validate it from the same screen instead of starting a separate log search.
• A hypothesis with the evidence behind it
Each insight includes a hypothesis, which is the engine's best explanation for what the logs show. Under it is a short list of recommended actions to check first. The hypothesis is a starting point, not a confirmed root cause. The matching logs stay on the same screen so an engineer can test the explanation before acting on it.
• Drilldown with the insight context
Every insight comes with a chat that already holds its context. Ask which services are affected, whether the errors started before a deploy, or to show the matching logs as a table. Answers cite the log lines they came from, so you can ask follow-up questions without starting another search or losing the insight you were looking at.
• How rules affect later scans
Admins can write rules in plain language, such as treating any payment service error as High. Those rules apply to later insights. Engineers can also mark an insight as a false positive, add a reason, and choose whether that feedback applies to one dataset or all of them. Similar patterns are downgraded in later scans instead of being deleted.
• The engine only analyzes your logs
The engine surfaces findings and suggestions. Engineers decide whether to investigate, suppress or act on them. AI answers can be wrong, so the matching logs stay attached for verification. Suppressing an insight hides it from the feed but does not delete the underlying logs. Rules can be removed at any time.
What changes for the engineer
Capability | What the engineer sees | Metric it can affect |
|---|---|---|
Pattern and anomaly detection | Findings appear without a new search | MTTD |
Severity and impact score | Findings are ordered by severity and impact | Triage time |
Matching logs and sample size | The evidence is attached to the finding | Investigation time |
Hypothesis and recommended actions | A starting theory and checks to run | MTTR |
AI Drilldown | Follow-up questions without rebuilding the search | Investigation time |
Rules and false-positive suppression | Known false positives are downgraded later | Alert fatigue |
Recurring-pattern view | Repeated patterns are visible across days | Repeat-incident rate |
The practical change is where an investigation starts. Instead of beginning with a blank search box, an engineer starts with a ranked set of patterns, the logs behind them and a hypothesis to check. The metrics in the table are the ones this workflow is intended to affect; CtrlB should only claim measured improvements when customer data supports them.
Three points in the incident lifecycle
During an incident. Higher-severity patterns appear at the top of the feed, with their matching logs attached. Triage starts from those findings instead of a blank search.
After an incident. A wider time range shows which patterns keep returning. That makes repeated failures easier to spot across incidents and gives the team concrete patterns to investigate in a postmortem.
Between incidents. Smaller anomalies can surface before they become customer-reported problems. The point is simple: engineers do not have to start a search just to find out what changed.
What it costs
The AI Insight Engine is part of the CtrlB platform, so there is no separate AI add-on or extra charge to use it. Your pricing is based on the data you ingest into CtrlB, with the Insight Engine included as part of the platform. You can see the full pricing details, including the available plans and usage-based pricing, view CtrlB pricing.
See how it works
See the AI Insight Engine in action in the Insights docs, where the detection flow, insight details, Drilldown and rules are shown with examples. The docs cover the feature in more detail.