Autopilot compute limits

New Relic Autopilot compute limits provides a level of budget governance to help better manage enterprise budgets. High-frequency observability events—such as incident alert storms or cascading condition failures—can trigger bursts of investigation prompts or analyses that can drive up costs for compute resources, potentially leading to invoice surprises. New Relic Autopilot compute limits helps to provide proactive, policy-based budgeting that allows you to implement certain operational boundaries for costs surrounding Autopilot runs.

Enterprise compute allocations are configured by Organization Managers as daily and monthly budgets denominated in Advanced Compute Capacity Units (Advanced CCUs). These roles can now create sub-budgets for System Identity (SI) workflows pertaining to New Relic Autopilot. Background alert investigations also contain their own dedicated allocation. Setting budgets for these actions help you better manage compute quota used during active incident investigations using Autopilot.

User roles and governance capabilities

Access control for Autopilot compute limits follows New Relic's Role-Based Access Control (RBAC) framework. The matrix below defines administrative authorities compared to read-only operational capabilities across platform workflows:

The following section details the administrative workflows and procedures required to configure compute limits within the New Relic platform.

Configure compute budgets (admin workflow)

Compute budgets allow managers to help enforce financial policies or budget policies with configurable, in-UI constraints. Using the New Relic user interface, administrators establish organizational limits that dynamically enforce desired limits on system execution across interactive sessions and background automation.

UI navigation and configurable parameters

To configure compute budgets, navigate to Autopilot Configuration Modal / Onboarding Panel > Compute Limits & Budgeting.

Administrators can define four core parameters within the configuration interface:

• Total Daily Autopilot budget (Advanced CCUs/day): Sets the enterprise-wide expenditure ceiling for all combined interactive user sessions and automated workflows per calendar day (evaluated in the organization's timezone).
• Automated and Async Daily Sub-Budget (Advanced CCUs/day): Allocates a dedicated daily sub-quota strictly for System Identity (SI) workflows, such as alert webhooks and workflow notifications.
• Total Monthly Autopilot budget (Advanced CCUs/month): Establishes the macro-level monthly compute budget ceiling across all Autopilot executions.
• Automated and Async Monthly Sub-budget (Advanced CCUs/month): Defines a dedicated monthly sub-allocation exclusively reserved for autonomous background investigations.

Parameter validation rules and backend conversion mechanics

The platform UI enforces input validation rules at the configuration entry gate to prevent invalid or conflicting policy states:

• Rule 1 (Sub-budget hierarchy): Automated sub-budgets must be strictly less than their corresponding total budget (Automated Sub-budget < Total budget).
• Rule 2 (Temporal multiplier): When both daily and monthly budgets are configured, the monthly budget must not exceed 30 times the daily budget (Monthly budget <= 30 * Daily budget).
• Policy flexibility: All limit parameters are optional. Organizations can configure partial policies (such as enforcing a daily total budget without a monthly budget) based on specific operational needs.

Admins set budget limits using a single metric (Advanced CCUs), creating an exact, non-negotiable spend limit that automatically blocks an AI from running up huge unexpected bills when doing fast, complex tasks.

Audit change log specification

Every configuration change is tracked in NrAuditEvent as follows:

Once administrative policies are saved and validated, the platform dynamically evaluates budget thresholds to enforce deterministic execution states for all users.

User experience and budget thresholds

Autopilot operates deterministically: requests execute with full multi-step model reasoning or are blocked at entry once budgets are reached.

State machine and execution behaviors

The system evaluates compute consumption across three operational tiers based on total spend against the configured budget:

UI error card display format

When an organization reaches 100% of its compute allocation, interactive chat sessions present the following standard error card:

⚠️ Autopilot Daily Compute Limit Reached

Your organization has consumed 100% of its daily allocated compute budget (Advanced CCU Limit Exceeded). Interactive reasoning and automated investigations are temporarily paused.

Next steps: Contact your New Relic Organization Manager to increase your budget, or retry after the midnight reset (00:00 UTC).

While interactive user sessions provide visual indicators and immediate error card feedback, automated background operations require dedicated processing lifecycles.

Real-time metric fetch failure and unavailable state

When the platform UI is unable to fetch real-time usage metrics from the backend telemetry cache, the system transitions to a non-blocking degraded visual state. Backend budget enforcement remains continuously active regardless of UI data availability.

• Status pill badge text: Displays Daily Usage: Unavailable ⚠ in the context bar.
• Contextual tooltip: On hover over the unavailable pill, displays: "Unable to fetch real-time usage metrics. Your backend budget enforcement remains active. [Retry]"

Automated alert triage and async System Identity (SI) workflows

Automated incident triage relies on System Identity (SI) workflows that process incoming alerts asynchronously. During major system outages, alert storms ("thunderstorms") can fire dozens of concurrent webhooks simultaneously. Dedicated SI sub-budgets insulate the background intake engine, ensuring automated alert bursts do not impact interactive human investigation budgets.

System Identity execution lifecycle

When an automated trigger occurs (for example, alert_webhook or workflow_notification), the execution path varies based on current sub-budget consumption:

Edge scenarios, concurrency budgets, and safeguards

Daily and monthly Advanced CCU budgets evaluate total cumulative spend, but they cannot prevent sudden event bursts where hundreds of incoming webhooks fire concurrently before usage can be processed and written to telemetry storage. To handle these edge scenarios, the platform employs defense-in-depth safeguards at the entry gate.

Alert storm mitigation architecture

To maintain platform stability and protect organization budgets during sudden alert spikes, two concurrent protection mechanisms operate at the entry gate:

• Per-org automated concurrency budget: Imposes a strict ceiling of maximum 20 simultaneous active automated runs per organization. Requests arriving while 20 automated runs are in-flight are shed immediately.
• Atomic Valkey reservations: Prior to spawning an asynchronous execution task (asyncio.create_task), the entry gate atomically increments high-speed Valkey counters by a conservative estimate. Upon run completion, the orchestration engine reconciles the reservation against actual consumption. If an initial reservation causes the organization's counter to exceed its configured limit, the transaction rolls back, and the request is rejected immediately.

High availability and disaster recovery: Valkey outage fallback policy

During local cache or Valkey infrastructure outages, the orchestration engine applies a tiered operational fallback policy:

Billing reconciliation, data lag, and disclaimers

Distributed system architectures maintain a structural separation between real-time entry gating and asynchronous billing metrics processing.

Counter architecture and pipeline skew reconciliation

The platform uses a dual-store model to balance low-latency enforcement with accounting accuracy:

• Real-time enforcement layer: Sub-millisecond Valkey counters evaluate entry gates to block over-budget runs instantly.
• Billing and reporting pipeline: Historical NRDB metric pipelines (resourceConsumption) aggregate data asynchronously, with an expected 2-hour processing lag.
• Margin of error absorption: Due to high-frequency execution concurrency, minor counter skew may create a temporary overshoot variance of 5% to 10%. New Relic absorbs all overshoot costs internally; customer accounts are never billed for usage that exceeds their explicitly configured hard budget.

Important callouts and limitations