Service Level Objectives give your team a shared, measurable definition of what "good" looks like for your AI services. Instead of reacting to user complaints or end-of-month cost surprises, SLOs let you set explicit targets — task success rate, response latency, agent availability — and get notified the moment those targets are at risk. For AI platforms, where an individual misbehaving agent can degrade an entire workflow, that early-warning layer is the difference between a proactive operations team and one that is always catching up.

SLOs work alongside the broader observability stack. For a full picture of how logs, metrics, and traces complement SLI data, see observability for AI agents. For alerting those SLO breaches to the right channel, see Slack and multi-channel alerting.

What SLOs mean for AI services

A Service Level Objective is a target value for a measurable quality indicator, agreed in advance. The measurable indicator is called a Service Level Indicator (SLI). For traditional web services, the canonical SLIs are availability (uptime), error rate, and latency percentiles. AI services add a dimension that traditional services do not have: task outcome quality, expressed as the rate of tasks that reach a successful terminal state versus those that fail, time out, or escalate.

This makes AI SLOs somewhat different from what a platform engineer used to managing APIs would expect. Error rate captures infrastructure failures and bad responses. Task success rate captures whether the agent actually accomplished what it was asked to do. Both matter, but they are not the same number, and optimizing one without watching the other produces a misleading picture of service health.

For operational purposes, the most useful SLIs for AI services cluster into three categories: task success rate (the fraction of completed tasks that succeeded), average latency (how long tasks take from dispatch to completion), and agent availability (the proportion of registered agents that are responding within their expected heartbeat window). These three numbers, tracked over a rolling time window, give you a working health summary for an AI deployment at any given moment.

Choosing the right time window

SLIs computed over the wrong time window produce misleading signals. A twenty-four-hour window averages over an entire day's traffic, which can mask a two-hour outage that occurred overnight. A five-minute window is too noisy for most AI workloads, where task volume fluctuates enough that a transient spike in failures looks like a trend. The right window depends on the volume and latency profile of your workload.

SLI summaries are available over a configurable rolling window ranging from one hour to thirty days. The default is twenty-four hours, which is appropriate for continuous workloads but may need adjustment for batch-oriented agents that run on a schedule. When evaluating availability during a period of low activity, a shorter window is often more informative, since longer windows smooth over an outage with the surrounding healthy period.

The rollup always reflects the window you specify rather than a fixed reporting cadence.

Setting alert thresholds

An SLO without an alert is a target you only check when something already feels wrong. Alert thresholds turn your SLOs into an active monitoring system: when a metric crosses the threshold, your team gets notified in time to act.

The SLO monitoring surface lets you configure per-metric alert thresholds for the three core SLIs. Each threshold specifies a metric, a comparison direction (above or below), a threshold value, and whether the alert is active. When the current SLI value crosses the threshold during evaluation, the alert fires.

You can optionally attach a webhook URL to an alert configuration. When the alert fires, a notification goes to that endpoint, making it straightforward to route SLO alerts into your existing incident management tooling — a Slack channel via a webhook integration, an on-call system, or a custom operations workflow. This keeps SLO monitoring in the same channel as other operational alerts rather than requiring the team to watch a separate dashboard. For guidance on securing those webhook endpoints, see webhook security: signing and verifying events.

Alert configurations are per-organization and scoped to the metrics that your deployment actually cares about. There is no requirement to configure alerts for every metric; you define thresholds only for the SLIs that warrant a response when they degrade.

Availability and agent liveness

Agent availability is computed from the live status of agents registered in your organization. The determination of whether an agent is available depends on how the agent communicates with the control plane.

Agents in direct mode — where the platform pushes tasks to the agent — are considered available if they have responded within a defined recency window. Agents in routed mode — where agents poll for pending tasks — use a longer recency window that accounts for their polling interval. The availability percentage in the SLO summary reflects the proportion of agents that are currently within their expected contact window.

This design means availability tracks the real operational state of your fleet rather than a synthetic probe. If an agent host goes down, the agent drops out of the availability count within one liveness window, and your alert threshold will catch it if you have configured one for availability.

Reading the SLO summary

The SLO summary surface shows your current SLI values alongside the alert thresholds you have configured. The summary refreshes against the window you have selected and gives you a clear view of which metrics are within target and which are approaching or have crossed an alert boundary.

For task metrics, the summary includes the total count of tasks processed within the window, the number that succeeded, the number that failed or timed out, the derived success rate, and the average latency. For availability, it shows the count of registered agents and the number that are currently live.

These figures are most useful when read relative to your configured thresholds. A 94% success rate is good or bad depending on whether your SLO target is 90% or 99%. The summary view shows both, so the gap between current performance and your agreed objective is immediately visible without mental arithmetic.

Integrating SLO data into incident workflows

SLO monitoring is most valuable when integrated into the workflow your team already uses for incident response. An alert that lands in an unmonitored dashboard is no better than no alert. An alert that arrives in your team's incident channel and carries relevant context is actionable.

The webhook integration on each alert configuration is the primary way to route SLO alerts into your incident workflow. By pointing the webhook at your incident management or alerting system, you ensure that an SLO breach triggers the same response process as any other production alert, rather than sitting in a separate monitoring surface that requires a separate check. Praesidia alert configurations are per-organization, so each team can direct alerts to the channel that makes sense for them.

SLO-related events also appear in the platform's standard event output, giving teams with established observability infrastructure a way to consume SLO state changes in their own tooling. For how those events flow to external systems, see webhooks and SIEM forwarding.

What SLOs do not replace

SLOs give you aggregate health signals, not root-cause analysis. When a success rate drops, the SLO alert tells you there is a problem; it does not tell you which agent is failing, why it is failing, or what the task queue looks like. For that, you need to move from the SLO summary into the task-level views and agent logs.

Think of SLOs as the fire alarm, not the fire investigation. They tell you something is wrong at the moment the pattern begins to emerge from the aggregate data, ahead of when individual users would report it. The investigation starts after the alert fires, using the detailed task and agent views alongside the audit trail.

SLOs also do not replace capacity planning. A latency SLO that is consistently near its threshold may indicate an agent fleet that needs more capacity, a model that is consistently slow for the task type in question, or a queue that is accumulating faster than it is being processed. SLO trends over time — available from the same rolling-window API with different window selections — give you the data for that conversation, but the analysis is still a human judgment.

Common questions

How do I pick the right success rate target? Start by measuring your current success rate over a representative period before setting a target. If your agents are currently succeeding at 92% of tasks, a target of 99.9% is aspirational but will generate constant alerts before you have made any changes. A realistic starting target is close to your current baseline, tightened gradually as you understand what drives failures. This avoids alert fatigue and gives the team time to address the actual causes of failures before they are judged against a target set without that information.

Can I configure different SLO targets for different agents? The SLO summary operates at the organization level, aggregating across all registered agents in the selected time window. For workloads where different agents have materially different performance expectations, filtering by agent at the task-analytics level gives you per-agent breakdowns. For per-agent breakdowns and advanced filtering, see advanced analytics for AI operations for how task-level views complement the SLO summary.

What happens if my webhook endpoint is unreachable when an alert fires? Webhook delivery is best-effort. If your endpoint returns an error or is unreachable at the time the alert evaluates, the notification is not automatically retried with exponential backoff. For critical SLO alerts, configure a webhook endpoint with high availability, or use a secondary alerting path such as in-app notifications to ensure you receive the alert even if the primary webhook delivery fails.

How do SLOs relate to the operations dashboard? The operations dashboard provides a real-time view of your AI estate — active agents, task throughput, recent failures — while SLOs provide the agreed targets against which that activity is measured. Use the operations dashboard for situational awareness during an incident, and use the SLO summary to establish whether performance has been within acceptable bounds over a rolling period. They answer different questions and are most useful together.