GigaOm Radar for AIOps v7

AIOps has moved from a correlation add-on to the layer where IT operations decides what happened, why it happened, and what to do next. The platforms assessed here reach that layer from three starting points (alert overlays, observability platforms, and IT operations and service management suites), and each starting point fixes what a product can see. Generative incident narratives and AI agents now appear across all three groups. The buying question has therefore shifted from whether a platform uses AI to how far its AI may act and how buyers govern, record, and pay for that action. Five themes capture where the field separates.

Where the Intelligence Sits Decides What It Sees

A minority of the field works on alerts that other tools raise, normalizing, deduplicating, and grouping them into incidents without collecting raw telemetry, so detection quality depends on the underlying monitoring tools. Observability-led platforms apply baselining, correlation, and investigation to metrics, logs, and traces they store themselves, and their depth tracks how much of the estate sends data to them. Suite-led platforms reason over a service model and configuration database shared with change and incident processes, which gives them business context but ties their value to the health of that record. Intake has broadened across all three groups. OpenTelemetry is common alongside syslog and SNMP, and pre-storage filtering is widespread, but a small group still collects only through its own agents and connectors.

What this means for buyers: Decide first which system will hold operational truth: the monitoring tools, an observability store, or the service management record. Choose an overlay when a broad monitoring estate is staying, an observability-led platform when telemetry is consolidating, and a suite when the configuration database is already trusted.

Agents Have Moved From Explaining Incidents to Acting on Them

Many platforms now expose findings, topology, or runbooks to external agents through an MCP server, so AIOps output increasingly feeds other automation rather than a console. Investigation agents that form hypotheses, show each query and tool call, and keep the run as a reviewable record are shipping in several products. Execution is more uneven. In a minority, an agent selects a runbook, runs it, and checks live telemetry to confirm that the service recovered. Elsewhere, the AI proposes a fix and an operator runs a workflow, or remediation passes to a separate automation product. Several agentic features remain in beta, preview, or announced status, and some platforms still automate only through configured workflows that no AI selects.

What this means for buyers: Ask each vendor to demonstrate, on your own incident data, which steps the AI performs and which steps a person performs, and whether the product or your team verifies recovery. Confirm general availability in writing for every agentic capability that influences the shortlist.

Topology Is Universal, but Freshness and Business Context Are Not

Where a platform updates its dependency model from change events as they occur, for example when a workload moves hosts or a deployment lands, correlation runs on the estate as it is. Others refresh on collection schedules, polling cycles, or imports, and some service maps cover traced microservices without the infrastructure beneath them. A single platform skips the graph altogether and correlates from learned event relationships, which removes the work of keeping a map current. Business context is the second split. Many products compute service health from the components beneath a business service and set priority from criticality or SLA exposure, while observability-led tools often carry ownership and tiers without that health model. Synchronization with a configuration database is common; automatic drift correction is not.

What this means for buyers: Test topology freshness during evaluation by moving a workload or deploying a change and timing how long correlation takes to reflect it. Where the configuration database is the system of record, plan drift reconciliation as a separate process rather than an assumed product feature.

Governance of the AI Itself Is the Weakest Layer

Controls over remediation are maturing faster than controls over models. Approval gates, separation between runbook authors and runners, version history, and test runs appear across much of the field, although rollback of an executed action is rare. Records of AI decisions vary more widely: some platforms keep each agent run with its tool calls, inputs, and outputs, while others log generic events that cannot reconstruct a decision. Model governance trails both. Most products let operators adjust sensitivity, baselines, or training windows, but few report model accuracy on customer data, keep model versions, or let operator corrections feed retraining. Platform security also varies. Customer-held keys and validated FIPS modules appear in a minority of products, and several self-hosted platforms leave some collection or database paths unencrypted until an administrator enables encryption.

What this means for buyers: Bring model governance and AI decision records into the security review, not only the operations pilot. Ask for an exported record of one agent run, the model version behind it, and the encryption settings that apply by default in the deployment model you intend to buy.

Pricing Units Diverge, and the Unit Shapes Behavior

Execution pricing ties cost to automation volume, ingest pricing ties it to telemetry growth, and device pricing ties it to the size of the estate, so each metering unit rewards a different behavior. Vendors license per monitored device, node, or resource; per gigabyte ingested; per correlated event or incident; per workflow or runbook execution; per agent; or per concurrent user. A few bundle AIOps into a platform commitment or a hardware support contract. Published list prices or rate cards are common but far from universal. In-product spend controls range from forecasts against customer budgets and enforced caps per team or account to no consumption view at all.

What this means for buyers: Model three years of cost under each vendor's own unit, using projected telemetry growth, automation ambitions, and estate size. Favor products that show consumption in the console and let you cap spend by team or environment, and negotiate contractual caps where the product does not enforce them.

Figure 1. GigaOm Radar for AIOps. Inner ring denotes Leaders and outer ring denotes Challengers; dot color carries market velocity.

Notable Patterns

The paragraphs below describe how vendors in this market populate each quadrant. Section 3, Tech Buying Triad, gives the standard quadrant definitions.

Foundation Builders are tied with Agile Optimizers as the most crowded quadrant, and that follows from what AIOps is. It works on telemetry it does not own, inside incident and change processes where a wrong correlation or an unexplained action becomes an outage of its own. Vendor-neutral event ingestion, deduplication, correlation tied to topology and the CMDB, and model logic an operator can audit are entry requirements rather than differentiators. Most of this activity is intelligence attached to an existing system of record.

Agile Optimizers are just as crowded, and they attack the cost of running that stack without replacing it. Intelligence arrives in four forms. It can be an overlay on monitoring and ticketing tools the buyer already runs or a tier of an incident-response or observability platform already deployed. It can also be agentic investigation that drafts the root-cause narrative an on-call engineer used to assemble, or approval-gated remediation. Autonomy is sold one approved action at a time.

Enduring Innovators are a much smaller group than the two crowded quadrants: mature causal engines extended with AI rather than superseded by it. Production-hardened topology models and service-level health scoring make the causal engine the foundation that other automation builds on. The AI added to that core ranges from governed agents that act on it to assistants that summarize data or propose steps for an operator to approve. The wager is that a proven causal model outlasts the AI layered on top of it.

Disruptive Pioneers are a small group, and each changed a core premise. Examples include self-healing as the default path instead of an approved exception, causality served to third-party agents instead of dashboards, and customer-owned agents instead of a vendor-hosted engine. The wager is that the traditional operations center will not last.

The quadrant descriptions and decision framework help buyers read this Radar from an enterprise procurement perspective. The Radar plots solutions on two axes: Operational Focus versus Strategic Focus, and Stability-Centered versus Evolution-Centered. Placement therefore signals both the outcome a product is meant to deliver and how it approaches change. This report maps decision responsibility to the Tech Buying Triad: the CIO owns Brown Money tradeoffs, the CTO owns Green Money tradeoffs, and the CISO owns GRCS tradeoffs. In AIOps, the CISO has become an active participant because agentic remediation puts automated actions on production systems. All three Triad roles consult on Emerging Technology inputs.

Quadrants

Foundation Builders

The goal is current operations that are more reliable, more consistent, and cheaper to run, without new sources of disruption. The typical sponsor is a CIO accountable for service commitments, often joined by procurement teams focused on multi-year cost certainty and by the CISO when compliance or data residency drives selection. These organizations run large, heterogeneous estates, frequently in regulated industries with long change-control cycles. They accept a slower pace of new capability in exchange for backward compatibility, long-term support, and predictable releases. They reject products that demand frequent re-architecture, introduce unpredictable ingest costs, or move faster than a change advisory board can absorb.

Agile Optimizers

These buyers want operational response to keep getting faster and better, and they accept frequent product change as the price. Sponsors include the CIO who owns operational KPIs and the engineering or platform leader who controls tooling decisions. These teams have usually consolidated onto a modern observability or incident stack and want detection, noise reduction, and automated response to improve in tight feedback loops. They expect to see gains in time to detect and time to resolve on short reporting cycles. They accept ongoing configuration and tuning work, and they reject products that lock capability behind long upgrade cycles or cannot show how operator feedback changes model behavior.

Enduring Innovators

These buyers expect AIOps to reshape operations at an architectural level, building capabilities that compound over several years without organizational disruption. The sponsor is a risk-aware CTO focused on platform longevity, or a CIO running AIOps as a named consolidation initiative with board visibility. These organizations usually have a mature platform or SRE function and complex hybrid estates, and they require governed, well-tested releases before broad rollout. They accept a longer time to value in exchange for architectural soundness, documented deprecation timelines, and a roadmap stable enough to build internal capability around.

Disruptive Pioneers

These buyers aim to reach a step-change operating model first, even at technical and organizational risk. Examples include agentic remediation, causal reasoning served to other agents, and generative incident intelligence. Sponsors include a CTO seeking architectural optionality and business leaders whose revenue depends directly on digital operations. These organizations have strong internal AI engineering and operate at a scale where threshold-based operations are already failing. They accept thinner support ecosystems and the governance overhead of high-autonomy AI, but they reject any product that cannot show transparent decision provenance and reversible action controls.

Axes

The X-axis: Operational Focus versus Strategic Focus describes the intended value, with Operational placements on the left of the chart and Strategic placements on the right. Operational products are bought to run the current estate better: fewer alerts, faster detection and resolution, and a lower cost of operation. Strategic products are bought to change the operating model, and their value compounds through a service model, a platform commitment, or an autonomy roadmap the organization builds around.

The Y-axis: Stability-Centered versus Evolution-Centered describes change posture, with Stability placements in the upper half of the chart and Evolution placements in the lower half. Stability-centered placements favor proven behavior, governed releases, and customer-controlled upgrades, and they treat change as a risk to manage. Evolution-centered placements treat change as the reward being purchased, from monthly feature drops to new agent capabilities that alter how incidents are handled.

Ring System (Leader Versus Challenger)

The Radar's concentric rings communicate overall capability depth and maturity independent of quadrant. This Radar uses two rings: Leader, the inner ring, and Challenger, the outer ring. A minority of platforms hold the inner ring.

Leader denotes platforms whose capabilities run broad and deep across the evaluation lenses, with production-grade correlation, root-cause analysis, and governance that are referenceable at enterprise scale.

Challenger denotes solid capability with important areas of growth: useful in many deployments, but likely to require more integration effort, operational validation, or adjacent tooling for specific enterprise requirements.

Use ring position as a procurement heuristic. Inner-ring placements reduce validation effort when a buyer's requirements match the vendor's strengths, while outer-ring placements call for a pilot and clearer contractual commitments. Ring position does not change which quadrant a product targets.

Archetype Variants

Different buyer archetypes shift weight across the Tech Buying Triad. Regulated buyers, including financial services and critical-infrastructure operators, tilt toward GRCS: approval gating of automated actions, AI decision records, encryption defaults, and attested compliance lead the evaluation. The CISO's accountabilities can carry a veto. Engineering-led buyers running cloud-native estates shift toward Green Money and CTO leadership, weighting root-cause precision, runbook extensibility, and integration depth. Cost-pressured operations teams elevate Brown Money and the CIO's accountabilities, led by noise reduction, faster detection and resolution, and licensing transparency. Any selection in this category succeeds only with explicit Triad alignment up front. Agree which bucket has the final say in a tie and which acceptance tests a product must pass before production.

Decision Matrix — Which Quadrant Fits Your Organization?

Use the profiles below to identify the quadrant whose typical buyer most resembles your organization. The row that sounds like your team points to the vendors that deserve your closest review.

Vendor Capsules by Quadrant

Enduring Innovators

These organizations are buying architectural change in how operations run, with capabilities that compound over several years. They accept a longer time to value in return for governed releases, documented deprecation timelines, and a roadmap steady enough to plan around.

Disruptive Pioneers

Buyers here pursue a step-change operating model, such as agentic remediation or causal analysis offered to other agents, and take on technical and organizational risk to reach it first. Thinner support and heavier governance are acceptable, provided every automated decision shows where it came from and every action can be reversed.

Foundation Builders

Large, mixed, or regulated estates with long change-control cycles look here for operations that are more reliable and cheaper to run. Predictable releases, long-term support, and stable costs matter more to them than a fast pace of new capability.

Agile Optimizers

Teams that have consolidated onto a modern observability or incident stack want operational response to keep improving. They accept ongoing tuning and frequent product change, as long as vendors do not hold capability behind long upgrade cycles.

Market-Level Velocity Story

Velocity on this Radar measures market momentum: the pace at which a vendor ships capability that moves the category, judged against the market's direction of travel rather than raw feature count. The Radar shows it as the color of each vendor's dot, never as an arrow. A few vendors are Outpacing, a single vendor is Slow Following, and the rest of the field is Fast Following.

That concentration reflects how quickly the category itself is moving. Through 2025 and 2026, most vendors shipped generative incident summaries, natural-language querying, MCP servers, and first-generation agents, and many renamed or repackaged their AIOps products around agentic positioning. Keeping pace with that baseline is demanding in its own right, so the Fast Following group holds vendors with active, dated release trains across very different product strategies. Vendors also differ in how much of their release activity they disclose publicly, and a thin public release history is not by itself a sign of a weaker product. Within that group, the practical differences lie in whether new capability is generally available, whether it reaches self-hosted deployments as well as SaaS, and whether it extends to remediation or stops at investigation.

Each Outpacing vendor recently moved an agent layer from announcement to general availability and paired it with an MCP server, so findings and actions reach automation outside the product. Their foundations differ, from a causal model of the estate to telemetry the platform already stores to a framework where customers build, version, and govern their own agents. Each also showed market traction alongside the product work, through funding, revenue growth, or new cloud marketplace listings. Even among Outpacing vendors, some closed-loop remediation features were in preview at launch, so the mark signals pace rather than finished autonomy.

Slow Following is reserved for clear, dated signs that product activity has slowed, not for an absence of news, and it is not a verdict on capability. The product carrying it remains a coherent answer to a specific operational problem, and a buyer for whom that problem is central should ask the vendor for a dated roadmap before assuming the pace will change.

For buyers, the practical instruction is to read velocity here as a measure of how quickly a vendor converts announcements into generally available capability. In a market where most vendors move at a similar headline pace, confirm which deployment models receive each agentic feature in a proposal, and weight dated delivery over roadmap language. A Fast Following vendor that ships dated, generally available increments can be a safer choice than a faster vendor whose agentic features remain in preview for the deployment model you need.

Technical Support Quality and Responsiveness

Support terms often arrive with a wider contract, because several AIOps products reach buyers through hardware support tiers or managed services agreements rather than standalone licenses. Most other vendors sell subscriptions in which support is part of the platform agreement, and trust centers, attestation portals, and published availability designs are common. Resilience commitments vary widely. Some platforms run active-active across data centers or fail over between availability zones with annual recovery exercises, while others offer high availability only for collectors or leave redundancy to the customer. Buyers should put severity definitions, response commitments, and escalation paths in writing, and confirm whether AIOps features carry the same support terms as the parent platform.

Professional Services Depth

Implementation effort concentrates in three places: service modeling, pipeline and agent composition, and runbook authoring. Products that compute business-service health from hand-configured dependency trees need modeling work before they deliver prioritization. Data-pipeline platforms need engineering capacity to compose pipelines and agents around a customer's own processes. Self-hosted products on Kubernetes, OpenShift, Windows, or Linux add installation, sizing, and upgrade work, and some vendors publish sizing calculators and certified volumes for that purpose. At the other end, overlays that ingest existing alerts and SaaS platforms with prebuilt integrations shorten the path to first value. During evaluation, size the services requirement, ask who performs service modeling and runbook migration, and tie the vendor's time-to-value claim to a named, dated milestone in the contract.

Partner and Channel Ecosystem Breadth

Several products are sold through AWS Marketplace listings or private offers, and a number of vendors publish MSP editions or name service providers as a primary audience. Integration catalogs are the other measure of reach, and the largest run to thousands of integration bots or workflow actions, with GitHub-hosted templates and Terraform resources appearing in some products. Two-way integrations that carry assignments, closures, or diagnoses back into ticketing and monitoring tools are less common than one-way intake. Before buying through a marketplace, check whether the purchase draws down existing cloud commitments, and test the specific bidirectional connectors your workflows depend on rather than counting catalog entries.

Workforce Skills Availability

Natural-language interfaces are lowering the skill barrier for first-line operators across much of the field. Assistants answer multi-entity, time-bounded questions, show the query they generated, and in several products create dashboards, monitors, or workflows from the conversation. Deeper administration still demands specialist skills. These include PromQL and vendor-specific query dialects, YAML and low-code workflow authoring, and Ansible or other automation frameworks behind remediation. Self-hosted deployments also need Kubernetes or OpenShift operations skills. Service modeling and topology curation remain scarce skills, because correlation quality in suite-led products depends on them. Teams should map each shortlisted product's administration surface to the skills they already employ, and budget for the gap, particularly where remediation runs through a separate automation platform the team does not yet operate.

Training and Certification Programs

Enablement mostly arrives inside the product rather than as a course. Vendors bring operators into automation through visual workflow builders, low-code automation studios, pipeline builders, guided drill-downs, and generated troubleshooting guides. Several products include libraries of prebuilt actions or fault-fix automations that teach by example. Generative assistants extend that pattern by explaining an investigation step by step. Organizations planning broad rollouts should request training catalogs, any certification paths, role-based learning paths, and enablement plans during procurement. They should also count the in-product authoring tools as part of the training estate when judging how quickly a team can become self-sufficient.

Community Health

Runbooks increasingly live in customer source control, Confluence, or GitHub rather than only inside a vendor's console. The same shift toward openness is visible in telemetry intake and agent interfaces, where open formats are already common. Several products integrate with open automation frameworks such as Ansible and StackStorm, while open-source heritage is rare. Openness matters here because AIOps sits on data and automation the buyer already owns. Favor products that ingest open telemetry formats, export AI decision records, and keep runbooks in formats the organization controls, so that switching platforms does not mean rebuilding the operations knowledge base.

No organization weights the decision criteria in this evaluation equally, and in AIOps, deployment-specific questions decide outcomes. Before shortlisting, pressure-test four things in order. First, root-cause accuracy on your own history: replay two or three past incidents with known causes and compare what each product names and the evidence it shows. Second, topology freshness under a live change. Third, the automation boundary: trigger a remediation and record which steps require approval and who can author versus run them. Fourth, cost under growth in each vendor's own metering unit. The table below indicates when to promote specific criteria to first-order requirements and when to let them recede.

Adapting the Radar to Your Organization. Start from your three or four non-negotiable criteria and re-read the vendor capsules against those alone. Let that reading reorder the field before you consider overall placement. A vendor positioned modestly on this Radar may be the outright leader for your weighting, and the reverse is equally true. Revisit that weighting after the pilot, because replayed incidents often expose priorities that the requirements document missed.

Capabilities Likely to Become Table Stakes (12–24 Months)

Several capabilities that separate vendors today are on a clear path to assumed status. Generative incident narratives that combine metrics, logs, traces, topology, and change records inside the incident workflow are already widespread, and summaries that restate a single alert will not survive procurement. MCP exposure of findings and actions is following the same curve, as buyers wire AIOps into their own agents and assistants. Natural-language querying that shows the generated query and its sources is close behind, along with saving an answer as a dashboard or monitor. Seasonality-aware baselines that need no hand-set thresholds belong on the same list. On the governance side, configurable human approval for automated actions and separation between runbook authors and runners are becoming procurement expectations. Buyers will also expect OpenTelemetry intake, pre-storage filtering, and in-console consumption reporting as a matter of course, and vendors without them will increasingly have to defend the omission.

Capabilities Likely to Emerge as Differentiators

The next separation is visible in this market's thinnest capabilities. Closed-loop remediation that selects a runbook, runs it, and confirms recovery from live telemetry ships in only a minority of products. Extending it to regulated estates will reward vendors that also rehearse actions against the real target and capture prior state for rollback. Model governance is the second front: reporting accuracy on the customer's own data, keeping model versions, and feeding operator corrections into retraining remain rare. Pre-deployment change control is third. Several products rate or simulate a planned change, but blocking a release that fails a customer-set policy is rare. Finally, cost governance will separate the field, because metering by execution, event, and agent invocation makes in-product budgets and enforceable caps as important as the features they meter. Business-transaction topology, which ties a technical fault to the order or payment it disrupts, is a further front that only a few products carry today.

Expected Market Consolidation or Fragmentation

The structural fact in AIOps is convergence from three directions. Observability platforms are adding correlation, agents, and automation. Service management and IT operations suites are adding generative and agentic layers to their configuration records. Independent overlays are repositioning around agentic operations. The market already shows the churn that accompanies convergence. Many of the products assessed carry a recent rename or repackaging, others arrived through acquisition or a change of ownership, and telemetry pipeline technology is changing hands as platforms extend their reach. Pricing models are converging as well, as several vendors move from device or seat licenses toward credits and consumption units that span observability, automation, and AI. For buyers, that churn makes contract language more durable than product names. Expect further consolidation. Establish in writing which capabilities live in the SKU being purchased, how AIOps features are licensed relative to the parent platform, and what commitments survive if the vendor or product line changes hands.

An AIOps platform is a reasoning layer in the middle of the IT operations value chain, between the tools that produce operational signals and the systems that act on them, which increasingly include other AI agents. Its job is to turn the first group's noise into decisions the second group can execute.

The differentiation in this field lives at the two seams. The upstream seam is contextual: how much of the estate the platform can see, how current its dependency model stays as the estate changes, and whether it carries business-service and change context into correlation. The downstream seam is executable: whether conclusions arrive as a narrative for a person, a workflow that runs behind an approval, or an agent action that verifies its own result. It also covers whether every step leaves a record an auditor can retrieve. Products strong at the upstream seam but thin at the downstream one hand remediation to adjacent tools; the reverse leaves agents acting on an incomplete map.

On lifecycle timing, this layer enters the architecture when the surrounding estate changes shape: a monitoring consolidation, a move to OpenTelemetry, a service management renewal, or a mandate to reduce on-call load through automation. The dependency runs in both directions, because the platform's value rests on upstream tools it does not control and on downstream workflows that encode years of operational knowledge. Exit is easier where telemetry stays in open formats, runbooks live in customer source control, and AI decision records export to the buyer's own storage. Choose the platform on the strength of its seams, and confirm before purchase that its service models, runbooks, and records can leave in a usable form.

The decision criteria that underpin this evaluation are grouped by the accountability lens they serve.

Brown Money

• BM1. MTTD and MTTR Reduction: Whether the product detects anomalies across metrics, logs, and traces, triages the resulting incidents automatically, and measures time to detect and time to resolve over time.

• BM2. Alert Noise Reduction: How the product deduplicates and groups alerts from several monitoring sources into incidents, and whether it shows where noise originates and recommends specific tuning changes.

• BM3. Service Topology and Context: Whether the product keeps a dependency map current across infrastructure and application layers and carries business context such as service health, criticality, and SLA exposure into priority.

• BM4. Operational Scalability: Whether the product operates at enterprise scale with sizing guidance and multi-team scoping, and whether detection and correlation quality hold as the monitored estate grows.

• BM5. Telemetry Ingestion Flexibility: How broadly the product ingests open-standard, legacy, and third-party telemetry, and whether it filters, routes, and parses sources before storage without hand-built mappings.

• BM6. Cost and Licensing Transparency: How clearly the vendor publishes the metering unit, inclusions, and variable charges, and whether the product shows consumption, forecasts spend, and enforces customer-set caps.

Green Money

• GM1. Topology-Aware Correlation Architecture: Whether correlation walks a dependency graph discovered from live telemetry and updated from change events as they happen, tying downstream alerts to their upstream cause.

• GM2. ML Model Lifecycle Management: How much visibility and control operators have over learned models, from accuracy reporting and feedback-driven training to version history, retraining schedules, and validation.

• GM3. Integration Ecosystem Depth: How far the product integrates bidirectionally with observability, service management, and cloud platforms, and whether customers can build connectors through a published API or SDK.

• GM4. Predictive and Change-Risk Analytics: Whether the product forecasts degradation and service-level incidents ahead of time, and rates, simulates, or blocks planned changes before they reach production.

• GM5. Runbook Extensibility Framework: How runbooks are authored, parameterized, versioned, and reused, and whether they can be managed through an API or synchronized from the customer's own repository.

• GM6. Root-Cause Analysis Precision: Whether the product names where an incident started, separates it from downstream symptoms, and shows the evidence and investigation steps behind its conclusion.

GRCS (Governance, Risk, Compliance & Security)

• GRCS1. Remediation Action Governance: Whether automated actions require configurable approval, separate authors from runners, can be rehearsed or rolled back, and are gated by risk or change windows.

• GRCS2. AI Decision Audit Trail: Whether each AI decision and agent run is recorded with its inputs, signals, tool calls, and outputs, then retained, exported, and protected against alteration.

• GRCS3. Operational Resilience Controls: Whether the product's own analysis services fail over automatically, recover across regions, and keep detection running when a data center or region fails.

• GRCS4. Encryption and Transport Security: How completely the product encrypts telemetry in transit and at rest, and whether customers can hold their own keys or rely on validated cryptographic modules.

• GRCS5. Compliance Framework Alignment: Which current certifications and attestations cover the product, and whether the vendor publishes responsibility matrices or packaged audit evidence for named frameworks.

Emerging Technology

• EM1. Generative AI Incident Intelligence: Whether generated incident narratives and recommendations draw on several telemetry types inside the incident workflow, extend to post-incident reviews, and reach external agents.

• EM2. Agentic Remediation Orchestration: Whether AI agents select or build multi-step remediation plans, run them through the product, verify recovery, and adapt each step to what the previous one returned.

• EM3. Natural-Language Operational Querying: Whether operators can ask plain-language questions spanning entities, time windows, and telemetry domains, see the sources behind each answer, and act from the conversation.

• EM4. Contextual Anomaly Detection: Whether learned, seasonality-aware baselines detect anomalies without manual thresholds, evaluate signals together with service context, and extend to deployments and business metrics.

*Vendors marked with an asterisk did not participate in our research process for the Radar report, and their capsules and scoring were compiled via desk research.

For more information about our research process for Radar reports, please visit our Methodology.

My mission is to deliver innovative and scalable solutions that enable data-driven decision making and business transformation. I have extensive knowledge and skills in big data, data warehousing, Apache Airflow, and Google Cloud Platform, where I hold three professional certifications. I enjoy collaborating with clients and partners, sharing best practices, and mentoring the next generation of data and cloud professionals.

GigaOm provides technical, operational, and business advice for IT’s strategic digital enterprise and business initiatives. Enterprise business leaders, CIOs, and technology organizations partner with GigaOm for practical, actionable, strategic, and visionary advice for modernizing and transforming their business. GigaOm’s advice empowers enterprises to successfully compete in an increasingly complicated business atmosphere that requires a solid understanding of constantly changing customer demands.

GigaOm works directly with enterprises both inside and outside of the IT organization to apply proven research and methodologies designed to avoid pitfalls and roadblocks while balancing risk and innovation. Research methodologies include but are not limited to adoption and benchmarking surveys, use cases, interviews, ROI/TCO, market landscapes, strategic trends, and technical benchmarks. Our analysts possess 20+ years of experience advising a spectrum of clients from early adopters to mainstream enterprises.

GigaOm’s perspective is that of the unbiased enterprise practitioner. Through this perspective, GigaOm connects with engaged and loyal subscribers on a deep and meaningful level.

© Knowingly, Inc. 2026 "GigaOm Radar for AIOps" is a trademark of Knowingly, Inc. For permission to reproduce this report, please contact sales@gigaom.com.