Frequently Asked Questions

Opstral is an AI-native platform for enterprise operations built for the operations teams that are overwhelmed by alert volume, manual incident response, and the growing complexity of distributed systems.

At the center is Sentinel AI — an autonomous intelligence engine that observes your signals, investigates anomalies, determines root cause, and takes corrective action — all without waking someone up at 3 AM.

It is designed for: enterprise NOC teams, SRE and platform engineering groups, IT operations leads at large enterprises, and any organization running hybrid or multi-cloud infrastructure at scale.

An honest enterprise timeline has three phases, and most of the duration is driven by your side of the work (security review, network access, credential provisioning, change-management approvals):

We are deliberately not promising a "live in 72 hours" experience — it would not be true for any serious enterprise. Your dedicated implementation lead walks the realistic plan with you in the kickoff.

• Discovery and scoping (typically 2-4 weeks): Joint sessions to map your highest-value use cases, target signal sources, integrations to wire first, and approval boundaries for automation.
• Implementation kickoff to first signals (typically 1-2 weeks after access is granted): Connector authentication, network setup, initial MOP (Method of Procedure) library selection. The pace here depends almost entirely on how fast your security and IAM teams can provision access.
• Shadow mode to graduated autonomy (typically 6-12 weeks): Sentinel observes and recommends while your team validates. Automation is enabled progressively, per MOP, per system, as confidence is earned.

No. Opstral sits on top of your existing observability and monitoring stack — it does not replace it. We integrate with tools like Dynatrace, Datadog, New Relic, Splunk, Prometheus, Grafana, PagerDuty, and many others.

Sentinel AI consumes signals from all your existing sources, correlates them intelligently, and acts — while those tools continue to do what they do. Think of Opstral as the intelligence and action layer that sits above your existing monitoring layer.

Yes — and we want to be honest about how an enterprise POC actually works. No serious customer hands over production access to a new vendor for a trial, and we would not ask for it.

What a typical POC engagement looks like:

If you need a different format — longer pilot, sandbox replay of historical incidents, parallel deployment in a non-prod region — we can shape the engagement to fit. Talk to our team and we will design it together.

• Discovery and scoping (2-4 weeks before the POC): Joint working sessions to understand your environment, the specific use cases you want to validate, the integrations that matter for those use cases, and the success criteria for the POC.
• POC environment setup: Sentinel runs in a dedicated POC environment we set up together. You provide representative sample data (alerts, logs, MOPs you would want automated). We wire 2-3 integrations that best illustrate your priority use cases — typically a monitoring source, an ITSM, and a notification channel.
• Showcase window (typically 3-5 working days): Live walk-throughs against your scenarios, with your team driving the use cases. You see Sentinel investigate, recommend, and (where you enable it) act, end-to-end.
• Outcome: A tailored report against your success criteria and a recommended scope for a production engagement, including the integration plan and phased automation roadmap.

Every enterprise customer gets a dedicated Customer Success Engineer who leads the onboarding. This includes connector configuration, initial MOP library setup, signal tuning, and training sessions for your ops team.

Professional services are available for custom MOP development, complex integrations, and change management programs — but many customers complete onboarding with just the CSE included in their plan.

Absolutely. Sentinel AI integrates natively with ServiceNow, Jira Service Management, and other ITSM platforms. Every automated action Sentinel takes is logged as a change record, incident update, or approval request — whichever your process requires.

You can configure approval gates for any MOP so that human sign-off is required before execution. This means autonomous operations and human governance coexist cleanly from day one.

Those platforms perform their respective functions extremely well, and Opstral is not designed to replace them. It sits above your existing operational ecosystem, continuously correlating telemetry, operational knowledge, incidents, deployments, topology and enterprise context into a unified Operational Intelligence Platform. It helps your teams understand what is happening, why it is happening and what should happen next, while leveraging the investments you have already made.

No. Observability tells you what happened. Operational Intelligence helps you understand why it happened, determines the appropriate response, coordinates enterprise knowledge and automation, and enables governed execution. Observability is an input to Opstral, not what it is.

Large platform vendors optimize individual domains extremely well. Our focus is understanding enterprise operations across heterogeneous environments. Enterprises rarely operate on a single vendor stack, and Opstral is designed to unify those ecosystems rather than extend a single vendor's platform.

We compare architectural layers rather than feature lists. ServiceNow provides ITSM, workflow, change management and the CMDB, and does those extremely well. Opstral operates in the layer above: operational intelligence, reasoning, cross-domain correlation, guided decisions and governed automation. The two augment each other; this is not a rip-and-replace conversation.

Our team has spent years building and operating enterprise-scale production systems. Opstral captures that operational experience inside the platform through operational knowledge, reasoning and automation. Experience is a stronger differentiator than algorithms.

Innovation in enterprise infrastructure has often come from focused companies solving specific problems exceptionally well. Opstral complements your existing enterprise investments rather than requiring a disruptive replacement, allowing you to adopt the platform incrementally while benefiting from focused innovation.

Enterprise operations have reached an inflection point. Over the last decade, organizations accumulated cloud platforms, Kubernetes, microservices, DevOps pipelines, observability tools, ITSM systems and security platforms. Each investment solved a local problem, but together they created an operational ecosystem that is increasingly difficult for humans to manage.

At the same time, enterprises are under pressure to adopt AI responsibly. Opstral addresses both realities by introducing an Operational Intelligence Platform that unifies existing systems, reasons across operational context and enables governed AI-assisted operations, without requiring you to replace your existing investments.

AI is an implementation capability, not the product. The product is an Operational Intelligence Platform. AI assists in understanding production state, investigating incidents, reasoning across enterprise knowledge, recommending actions and orchestrating governed automation.

Absolutely. Which is why the platform continuously measures confidence, provides explainability, follows enterprise policies and supports human approval before executing any production-changing activity. Any AI can be wrong; the difference is whether the platform is engineered for that reality.

Trust in production is a governance question more than an AI question. Opstral is built around enterprise policies, explainability, confidence scoring, human approvals, a complete audit trail, rollback and approval workflows. Autonomy is graduated: the platform earns trust with evidence, not promises.

Recommendations are always accompanied by supporting evidence, confidence levels and the reasoning behind them. Production-changing actions can be governed through enterprise approval policies and your existing change management processes, and executed actions remain reversible and audited.

Initial operational visibility and AI-assisted investigation can typically begin within weeks. Broader operational intelligence and automation mature over the deployment lifecycle, as confidence is earned and autonomy is graduated.

With concrete KPIs, agreed at the start and measured against your own baseline:

• MTTR and MTTD reduction
• Context-switching reduction
• Automation coverage
• Incident recurrence
• Operational effort saved
• Change success rate
• Knowledge reuse

No. Our objective is to amplify experienced operations teams by removing repetitive investigation and coordination work, allowing engineers to focus on higher-value operational decisions.

Customers typically begin with unified operational visibility and AI-assisted incident investigation. As confidence grows, they progressively adopt operational knowledge management, governed automation, autonomous runbooks, SRE assistance and broader operational intelligence.

No. Sentinel AI is the intelligence component inside Opstral, not a separate product and not a separate purchase. You do not buy or license Sentinel on its own; it is included with the platform. The same applies to ProcBot, Sherlock, Integration Connectors, the Data Governance Fabric, the Alerts and Rule Engine and Data Ingestion & Transformation: they are underlying components, each specialised for its job, and they all come with Opstral.

They are specialised components built into Opstral. ProcBot executes procedures through approved, reversible Action Tickets. Sherlock validates every fix and closes the RCA loop. Integration Connectors is the connectivity layer that provides 2,000+ governed connectors. None of them is sold separately. When you purchase Opstral you get all of them as part of the platform; you are not buying Integration Connectors, or any other component, as a standalone product.

No. Take only the pillars you need. Opstral integrates with the tools you already run and provides native observability only where you have gaps. You can start with one or two domains and expand over time; the platform and its components stay the same underneath.

OIAO stands for Observe — Investigate — Act — Optimize. It is the four-phase intelligence loop that powers every decision Sentinel AI makes:

The entire cycle happens in minutes — compared to hours with manual processes.

• Observe: Sentinel ingests signals from all connected monitoring tools, cloud APIs, logs, metrics, and traces. It normalizes and correlates events across sources in real time.
• Investigate: When anomalies are detected, Sentinel runs automated root cause analysis — tracing signals across topology maps, historical patterns, and change records to determine what actually caused the issue.
• Act: Based on the investigation outcome, Sentinel selects the appropriate MOP (Method of Procedure) and ProcBot executes it — a structured autonomous runbook with pre-checks, execution steps, and validation.
• Optimize: Every resolved incident is reviewed by Sherlock, the validation and optimization engine, to learn patterns, improve future detection, and recommend enhancements to your MOP library.

Sentinel AI uses a confidence scoring system before taking any action. Every investigation produces a confidence score — and Sentinel only executes autonomously above a configurable threshold you set. Below that threshold, it escalates to a human with the analysis and recommended action pre-filled, so the human decision is faster and better-informed, not bypassed.

Accuracy depends heavily on signal coverage, historical baseline quality, and how well-scoped your MOPs are. After a sufficient baselining period, Sentinel reliably identifies root cause on the majority of recurring incident types — and the threshold gates the rest into human review. We do not publish a single accuracy number because it would not be meaningful out of context; we measure and report it against your own environment during the POC.

If Sentinel does get something wrong on an autonomous action, every MOP includes post-execution validation and an automatic rollback sequence if validation fails. No silent failures.

A traditional runbook is a document — a list of steps a human reads and follows. A MOP (Method of Procedure) is an executable, structured operational program that Sentinel can run autonomously.

MOPs include: pre-execution safety checks (verifying conditions are right before acting), step-by-step execution with dependency management, post-execution validation (confirming the action worked), and automatic rollback if validation fails.

Opstral ships with a growing library of pre-built MOPs covering common incident patterns across cloud, Kubernetes, network, database, and security domains. The library is expanded continuously based on the use cases customers bring us. For anything specific to your environment, you can build custom MOPs using the no-code MOP builder or the programmatic SDK.

Yes. Sentinel AI was designed for heterogeneous environments. It natively supports AWS, Azure, Google Cloud, and on-premises infrastructure simultaneously. It can correlate signals across cloud providers — for example, an AWS RDS issue affecting an Azure-hosted application will be tracked as a single incident, not two separate alerts.

Our topology mapping engine builds a real-time graph of your full environment — services, dependencies, and cross-cloud relationships — so Sentinel always has the full picture before it acts.

Sentinel's correlation engine groups related alerts into a single incident context before any action is taken. It does not respond to individual alerts — it responds to root causes. So a storm of 2,000 alerts from a cascading failure is treated as one incident, with one investigation and one coordinated response.

Additional safeguards include: rate limiting on MOP executions, blast radius analysis before any infrastructure change, and a circuit breaker that pauses automation and escalates to humans if anomalous patterns are detected in the automation itself.

Sherlock is Sentinel's post-incident validation and optimization engine. After every resolved incident — whether resolved autonomously or by a human — Sherlock reviews what happened, what worked, and what could be improved.

Sherlock outputs: updated confidence thresholds based on outcomes, new MOP recommendations for recurring issue patterns, infrastructure optimization suggestions (rightsizing, configuration drift alerts), and trend reports that surface systemic issues before they cause incidents.

Over time, Sherlock makes Sentinel smarter and surfaces systemic issues that would otherwise stay buried in alert noise — so you see not just faster resolution, but fewer incidents altogether. The actual reduction varies significantly by environment, signal quality, and how aggressively recommendations are acted on; we measure it against your own baseline rather than promising a fixed percentage.

Yes, and this is a key part of our platform's value. We provide three ways to build custom MOPs:

All custom MOPs go through the same safety architecture as built-in MOPs — pre-checks, validation, rollback — and they are versioned and auditable.

• No-code MOP Builder: A visual drag-and-drop interface to define steps, conditions, and validations without writing code.
• MOP SDK: A Python-based SDK for engineers who want to write MOPs programmatically with full control over logic, API calls, and decision trees.
• MOP Conversion: Our team can convert your existing runbook documents into executable MOPs as part of onboarding.

Sentinel has no write access to your systems. It observes, correlates and reasons, but it cannot change anything. Every change is executed by ProcBot, and ProcBot will only execute a change wrapped in an Action Ticket. There is no other path into your environment.

An Action Ticket is created before anything runs and records the exact MOP version selected, the target systems and blast radius, the pre-check that must pass, the post-check that defines success, the automatic rollback path, the evidence behind the decision with citations, and the identity that authorised it — policy or a named human.

Whether it executes on its own is decided by the impact of the fix, not the model's confidence in its diagnosis. If the remediation carries no service impact, it runs under policy: pre-check, execute, post-check, verify, with automatic rollback if the post-check fails. If it carries service impact, the ticket is raised and held — the owning team and change stakeholders are notified with the proposed MOP, blast radius and rollback path attached, and nothing executes until a named human approves.

Only pre-approved MOPs are eligible; there is no free-form command execution. Autonomy is granted per use case and per system rather than globally, and you can require approval for any class of action regardless of assessed impact, or withdraw autonomy for any scope at any time. See the security page for the full mechanism.

Full control, always. Opstral uses a graduated autonomy model. For every system, MOP type, or incident category, you can independently configure:

You can set different levels for different systems — for example, full autonomy for Kubernetes scaling events but approval gates for database schema changes. These settings can be changed at any time.

• Fully Manual: Sentinel observes and recommends, but humans make all decisions
• Approval Gate: Sentinel proposes actions and a human approves before execution
• Supervised Automation: Sentinel acts, but a human can halt execution at any step
• Full Autonomy: Sentinel acts and reports outcomes asynchronously

Every MOP includes a post-execution validation phase. After each step, Sentinel verifies the expected outcome using health checks, metric thresholds, and service validation probes. If validation fails, the MOP automatically triggers its rollback sequence — reversing any changes made during that execution.

If rollback also fails, Sentinel escalates immediately to the on-call team with a full execution log, what was attempted, what failed, and recommended manual next steps. No silent failures, ever.

Every action is fully audited with a timestamped execution log available in the platform dashboard and exportable to your ITSM system.

Sentinel natively supports maintenance windows and change freeze periods. During these periods, you can configure Sentinel to: pause all automated actions, require additional approvals, or restrict execution to read-only diagnostic MOPs only.

Change freeze calendars can be synced from ServiceNow, Jira, or defined directly in the platform. Sentinel respects these windows automatically and queues any proposed actions for post-freeze review.

Yes. When human escalation is needed, Sentinel integrates with PagerDuty, Opsgenie, and Splunk On-Call (formerly VictorOps) to page the right on-call engineer based on the service affected, the team owning that service, and the current on-call rotation.

The escalation notification includes Sentinel's full investigation summary, confidence score, and recommended action — so the engineer arrives at the incident fully briefed, not starting from scratch.

Every action taken by Sentinel AI is fully logged in an immutable audit trail that includes: the triggering signal, the investigation reasoning, the MOP selected, every step executed, who (or what) approved the action, and the validation outcome.

This audit trail is available in the platform dashboard, exportable to your SIEM (Splunk, Elastic, etc.), and can be pushed to ServiceNow or Jira as change records and incident updates. For regulated industries, this audit capability is foundational to compliance.

We integrate across the major enterprise observability, ITSM, alerting, cloud, and collaboration vendors. Representative coverage:

If a tool you need is not yet on this list, our Connector SDK supports custom integrations and we add new native connectors based on customer requests. During scoping we confirm coverage for the specific tools in your stack.

• Monitoring & observability: Datadog, Dynatrace, New Relic, AppDynamics, Splunk, Prometheus, Grafana
• Cloud: AWS CloudWatch, Azure Monitor, Google Cloud Operations
• ITSM: ServiceNow, Jira Service Management, Freshservice, BMC Remedy
• Alerting & on-call: PagerDuty, Opsgenie, Splunk On-Call (formerly VictorOps)
• Collaboration: Slack, Microsoft Teams, Google Chat
• Kubernetes & delivery: Native K8s API, Helm, ArgoCD, Rancher

Our ServiceNow integration is bidirectional. Sentinel AI can read open incidents and change records, create and update incident tickets automatically when it detects and resolves issues, log MOP executions as change records, and trigger approval workflows for high-impact actions.

For teams who want Sentinel's investigation and recommendations visible directly inside the ServiceNow incident interface, we can deploy a native ServiceNow integration (update sets / scoped app) tailored to your instance during onboarding.

Yes. Sentinel's Incident Communication Engine automatically posts updates to designated Slack channels or Teams channels at configurable intervals during an active incident. Updates include: current severity assessment, investigation status, what Sentinel is doing (or has done), and estimated resolution time.

You can also create a dedicated war room channel per incident, with Sentinel as an intelligent bot participant — answering diagnostic queries, posting timeline updates, and summarizing the post-incident report when the issue is resolved.

Opstral processes your telemetry (events, metrics, logs, traces) to power Sentinel's investigation and decision-making. Sensitive fields can be excluded or redacted before logs are sent to a model, raw payloads are not retained, and no customer data is used to train shared models. For strict data-residency needs, on-premises and air-gapped deployments keep all processing, including the model, inside your own infrastructure.

For customers with strict data residency requirements, we offer regional deployment options (US, EU, APAC) and a private cloud/on-premises deployment model where all processing stays within your own infrastructure. No customer data is used to train shared models.

Sentinel uses least-privilege service accounts with scoped permissions for each integration. We support OAuth 2.0, API key vault integration (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), and role-based access control that mirrors your existing IAM policies.

All credentials are encrypted at rest (AES-256) and in transit (TLS 1.3). Sentinel never stores plaintext credentials, and all authentication events are logged in the platform's security audit trail. Permission scopes are reviewed as part of our onboarding security review.

Yes. We offer a fully on-premises deployment option where Opstral runs entirely within your data center or private cloud. This includes the Sentinel AI engine, the MOP execution runtime, the dashboard, and all data storage. No data leaves your perimeter.

Air-gapped deployments are supported for government and defense customers, with offline model updates delivered via verified artifact packages. Contact our enterprise team for architecture details specific to your security requirements.

We support three deployment models to match your operational and compliance requirements:

All three deployment models support the full Sentinel AI feature set.

• Cloud (SaaS / Managed): Deployed on your preferred cloud using managed services — CaaS for the Opstral microservices and PaaS for stateful components (databases, queues, object storage). Sentinel AI's reasoning runs against any cloud-hosted or GPU-backed LLM (your choice of provider). We operate the platform; your data stays in your cloud account.
• Private Cloud / VPC: Same architecture as above, deployed into your own AWS, Azure, or GCP account. You own the infrastructure and the data; we manage the application lifecycle. A common choice for regulated industries such as financial services and healthcare.
• On-Premises / Air-Gapped: Deployed entirely inside your data center on Kubernetes. We support either setting up Kubernetes and the surrounding infrastructure for you, or deploying onto your existing cluster. Stateful workloads (StatefulSets, storage classes, secrets) are deployed and managed jointly with your engineering team for full transparency and operational control. Supported for defense, government, and regulated enterprise environments.

Cloud deployment: No infrastructure footprint on your side. We provision and operate the Opstral microservices on managed CaaS / PaaS, and connect to a cloud-hosted or GPU-backed LLM of your choice. You only need network connectivity to your monitoring tools and the integrations you want wired.

On-premises deployment: Runs on Kubernetes. We can stand up the Kubernetes cluster and supporting infrastructure for you, or deploy onto your existing platform. The stateful tier (StatefulSets, storage, secrets) is deployed and managed jointly with your engineering team so you retain full visibility and operational control. Exact sizing depends on signal volume, integration count, and the AI workload profile — we size it together during scoping.

Sentinel AI does not ship with pre-trained models for your infrastructure. What it ships is a set of core AI capabilities — reasoning, investigation, correlation, and MOP execution — that run against the LLM you choose (cloud-hosted or GPU-backed). You control which model family powers the investigation step.

The learning of your environment happens against your own data, during a baselining period: typical traffic patterns, expected error rates, service dependencies, and historical incident patterns. Sentinel observes and learns from your signals first, then acts only above a confidence threshold you set.

This is separate from integrations — the wired connections to your monitoring, ITSM, cloud, security, and data tools. Integrations are what let Sentinel see your environment; the baselining is what makes it useful in it. Time-to-production-grade autonomy depends on signal coverage, integration depth, and how aggressively you enable automation per use case — we set realistic milestones with you during scoping rather than promising a fixed timeline.

We do not lead with pricing, and we deliberately do not publish a price list. The right starting point is understanding your environment, the operational problems you are solving for, and the outcomes you need.

Once we have a solution that fits, the pricing conversation follows. The fastest path there is a short working session with our team. Let's connect and we will scope it together.

Opstral is built for enterprise environments with meaningful operational complexity. We work with each customer to define a commitment that makes sense for their use case, scope, and rollout pace — rather than enforcing a one-size-fits-all minimum.

We typically recommend starting with a scoped POC engagement to validate the specific use cases that matter to you before any longer-term commitment. Let's connect to discuss what shape works best for your team.

We deliberately do not publish a single "typical ROI" number, because returns depend entirely on your starting baseline — current MTTR, on-call load, alert volume, incident frequency, NOC headcount, and the maturity of your existing automation. A number that is exciting for one customer is unremarkable for another.

What we do every time is build a tailored ROI model with you during scoping — grounded in your own incident data and operational costs — so the business case is your numbers, not ours. Let's connect and we will run it with you.

AIOps (Artificial Intelligence for IT Operations) is the application of AI — machine learning, large language models, and reasoning engines — to automate and optimize enterprise IT operations. Traditional AIOps platforms focus on alert correlation and noise reduction, surfacing insights to human operators who still have to investigate and act.

Opstral goes further: Sentinel AI not only observes and investigates incidents but also autonomously executes resolution procedures (MOPs) via ProcBot, validates outcomes through Sherlock, and continuously optimizes the procedure library. The platform unifies ten operational pillars under a single intelligence layer — Service Ops, Infra Ops, AI Ops, Data Ops, Fin Ops, Process Ops, Security Ops, DevSec Ops, Telemetry Ops and Managed Ops, with ProcBot (execution) and Sherlock (validation) as included components — unifying fragmented point tools into one closed-loop autonomous system, without replacing them.

Sentinel AI is the central intelligence engine that powers the Opstral platform. It implements the OIAO loop — Observe, Investigate, Act, Optimize — across every enterprise operations domain.

Sentinel ingests signals from 2,000+ integrations across monitoring, ITSM, cloud, security, data pipelines, and AI/LLM systems; correlates them in real time to identify root cause; selects and executes the appropriate MOP (Method of Procedure) via ProcBot using Ansible playbooks, shell commands, or ITSM workflows; and validates resolution through Sherlock with learnings fed back into the system. Where traditional AIOps stops at recommendation, Sentinel AI executes — autonomously, with full audit trail, and continuously improving from every resolved incident.

Traditional AIOps platforms — Moogsoft, BigPanda, Dynatrace AI, Splunk ITSI — focus on alert correlation, anomaly detection, and surfacing insights, but they stop at recommendation. A human still has to investigate, decide, and act. PagerDuty excels at on-call scheduling and paging the right human, and its Automation Actions can run a Runbook Automation job, triggered by a responder or by an Event Orchestration rule. What sits outside that is the investigation that decides which job is warranted, and a gate that scores the blast radius of running it.

Opstral closes the loop. Sentinel AI detects and analyzes incidents; ProcBot autonomously executes resolution procedures (Ansible playbooks, shell commands, ITSM workflows); Sherlock validates the outcome; and learnings feed back to improve future runs.

The other key difference is scope. Most AIOps tools cover only one or two operational domains. Opstral unifies ten pillars under one intelligence layer: Service Ops, Infra Ops, AI Ops, Data Ops, Fin Ops, Process Ops, Security Ops, DevSec Ops, Telemetry Ops and Managed Ops, with ProcBot (execution) and Sherlock (validation) as included components. Opstral reduces MTTR and resolves common alerts without human intervention.