Skip to content

AI Observability & SRE

Read your systems. Pick your next move.

AI Observability & SRE puts system data, incidents and business context in one place for focused investigations.

From symptom to probable cause
Service topologyapi-gatewaycheckout-apiinventorypaymentscachepayments-dbReplica lagTelemetry · last 30 minutesLatencyErrorsTracesChange detectedInvestigation1Alert: checkout latency2Correlate: payments-db lag3Probable cause: replica lag4Runbook proposed, needs approval
  1. Alert: checkout latency
  2. Correlate: payments-db lag
  3. Probable cause: replica lag
  4. Runbook proposed, needs approval
Topology and telemetry in one view; fixes run only after approvalcheckout-api incident

The problem

Healthy on one layer. Failing for users.

A server can look healthy while requests still fail, so AI Observability & SRE shows each signal separately.

The value is context, not more charts: what changed, which system was involved and what evidence supports the next step.

Entitycheckout-serviceHost · service · cloud resource
MetricsWhat changed, by how much, and when?
LogsWhat did the system record around that moment?
TracesWhere did a request spend time or encounter an error?
EventsWhich lifecycle or configuration changes occurred?
A name is not an identity. Hostnames and IP addresses can change or be reused, so evidence is tied to the observed entity and its source.

How it works

Ask a question. Follow the evidence to a response.

Connect one approved data source first, check what arrived, then pick the view that answers your question.

  1. CollectCloud integrations, Linux Host Agent, OpenTelemetry, databases and RabbitMQ. Verify collection health.
  2. ObserveWorkloads, service health, topology, network, change log and internet exposure.
  3. See metrics, logs, traces and events for one time window, with an incident timeline.
  4. RespondMonitors, synthetic checks, notifications, tickets, dashboards and reports.

Observe and investigate

Begin at the resource. Let the evidence lead.

Workloads

One evidence page per system, so you don't search for the same server in every view.

Service health

Resource state across connected accounts, to narrow attention before opening every workload.

Topology

See how resources, servers, services and dependencies connect, so you know what to check next.

Network and exposure

VPC traffic, data transfer context, reachability and what workloads expose publicly.

Change log

Recorded configuration changes compared with health changes in the same window.

Databases

Supported engines, collection coverage and database recommendations.

AI Observability & SRE intelligence

Four AI tools, one for each question.

AI organizes evidence and suggests next steps, but can’t invent data that was never collected.

Agents

What did the investigation agents do for this incident?

Run result, timeline, risks and an audit view.

Analyzer

What needs attention across my cloud environment?

A dated health check by area: service health, speed, errors, logs, cost, reliability and coverage.

Code

Could this application error need a code change?

A repository-grounded proposal and diff a developer reviews before a draft pull request.

Ask

What can the available data tell me about this workload or change?

A scoped conversation with cited evidence, follow-up questions and stated limitations.

Investigation run · INC-181Completed
ResultFlowTimeline
LeadMetricsLogsTopologyChange
Proposed causeHost memory pressure behind scheduler allocation failures
Checks12Model confidence76%IncidentNeeds a person
Suggested fixRaise the memory limit on the scheduler poolNeeds approval

Confidence is the model's estimate, not a guarantee, so check the metric, log or trace behind each claim.

People stay in control

Investigation is not execution

Your team sets the rules for every fix, including who approves, what’s allowed, safety limits and a kill switch.

  1. SignalA monitor or signal opens an incident
  2. InvestigateSingle agent or agent team builds a plan
  3. RecordTicket in Jira, ServiceNow or an INC number
  4. ApproveApproval rules decide who signs off
  5. ExecuteOnly enabled actions, within limits
  6. VerifyCheck that the system recovered
Kill switchStops execution across the organization. Turning on investigation is never the same as allowing a live fix.

Costs and optimization

Tie infrastructure cost to business outcomes.

Cost views show what’s unassigned or incomplete, so a number never looks more complete than it is.

Unit economics

Relate infrastructure cost to customers, products, teams and business units.

Cost attribution

Decide how spend maps to your business categories, and review what's still unassigned.

Optimization opportunities

Cost and usage details for resources worth a look, to help the owner decide.

Collect data

Connect the data source that holds the answer.

Cloud integrations, the host agent and request tracing each show something different, so use them together.

AWSMicrosoft AzureGoogle CloudKubernetesGitHubJiraLinux Host AgentOpenTelemetry (OTLP)DatabasesRabbitMQEmail (SMTP)

Frequent questions

Can AI Observability & SRE change my systems on its own?

Finding a cause never changes anything, and fixes run only with approval, limits and a kill switch.

Connect what answers your question: cloud accounts, the Linux Host Agent, OpenTelemetry tracing, or database and RabbitMQ collectors.

No. Confidence is the model’s estimate, and every finding links to its evidence so a person can check it first.

The AI model your organization sets up in Settings, such as Azure OpenAI, AWS Bedrock or an OpenAI-compatible service.

Capabilities

What comes with AI Observability & SRE.

Book a demo

Start with a question, not a dashboard.

See how AI Observability & SRE turns a question about your systems into a focused investigation, using examples like yours.