This page is part of Observe's Fair Usage Policy. Alongside your account-level compute entitlement, Observe applies limits to individual workloads. These exist to protect your account as they prevent a single misconfigured Monitor, query, or Dataset from consuming a disproportionate share of your compute and degrading the experience for your other users. Most are configurable, and all are visible to you.

Monitor Governor

The Monitor Governor limits the compute cost of any individual Monitor. It addresses a common pattern where a single Monitor with expensive OPAL, such as OPAL using large joins, time travel, or wide window aggregations, quietly consumes hundreds of OCC per day.

Each Monitor is assigned a daily credit limit 100 OCC per day. This limit is roughly 80x the compute of an average Monitor, so in normal use you are very unlikely to ever reach it. The limit exists to catch major outliers, like a single misconfigured or runaway Monitor, rather than to constrain everyday monitoring.

The system evaluates each Monitor's compute every hourly, over a window of 24 hours to 7 days.

State	What it means
Normal	The Monitor is running within its daily limit.
Grace Period	The Monitor has exceeded its limit. Its creator and editor are notified by email, and a countdown begins, giving you time to optimize the Monitor's definition. Monitors can be in the Grace Period for 14 days before they become Compute-Disabled.
Compute-Disabled	The grace period ended with the Monitor still over its limit, so it has been automatically disabled.

A Monitor moves through three states: If a Monitor's compute returns within budget for more than three days, it returns to Normal. A Monitor that was previously Compute-Disabled receives a shorter grace period if it exceeds its limit again.

If you have a Monitor with a legitimately high-compute use case, reach out to your Technical Account Manager or account team to explore options. Otherwise, the Grace Period is your signal to tune the Monitor — see Monitor anti-patterns for common fixes.

Per-user and per-Dataset limits

You can isolate the impact of heavy usage so that one user or one workload does not affect your whole account:

Per-user limits cap the compute any single user can consume, so a single expensive session does not affect everyone. Set these in Credit Manager.
Dataset and dashboard limits let you set compute boundaries on individual Datasets and dashboards rather than relying solely on account-level controls.

Acceleration limits

Dataset acceleration is one of the largest drivers of compute consumption. The Acceleration Manager lets you view and adjust how often each Dataset is processed, so you can loosen intervals on non-critical Datasets and keep acceleration cost in line with the value each Dataset delivers.

📘
Note
These limits protect your account's performance and are separate from the account-level entitlement described in Compute entitlement. A workload can hit a per-workload limit even while your account as a whole is well within its entitlement.