Configure consumption control for pay-as-you-go computing jobs - MaxCompute

MaxCompute's pay-as-you-go resources scale on demand, so a single runaway SQL job or an unexpected spike in daily usage can drive up costs quickly. To prevent that, MaxCompute lets you set hard limits at two levels:

Control mechanism	What it limits	How it works
Per-statement resource limit	Resources a single SQL statement can consume	MaxCompute estimates the cost before running the statement. If the estimate exceeds your limit, the statement is rejected immediately.
Daily cumulative spend limit	Total standard SQL spend in a project per day	MaxCompute tracks cumulative spend from 00:00:00 to 23:59:59 (UTC+8). If the running total plus the estimated cost of a new statement would exceed the limit, the new statement is rejected.

Both mechanisms are hard blocks — there are no graduated warning levels. Pair them with DataWorks intelligent monitoring to get notified when jobs are blocked so your team can intervene manually.

Daily cumulative spend figures represent metered (unbilled) usage and exclude any discounts or promotions.

Per-statement resource limit

This limit prevents a single SQL statement from consuming more resources than expected. MaxCompute calculates a statement's estimated resource consumption as:

estimated consumption = SQL read volume (GB) × SQL complexity

This value is referred to as m_value. It represents an estimate of resource usage, not the actual billed amount.

Set the limit for a project

Run the following command as the project owner or a user with the Super_Administrator role:

-- Set the limit
SETPROJECT odps.sql.metering.value.max=<m_value>;

-- Remove the limit
SETPROJECT odps.sql.metering.value.max;

Replace <m_value> with the maximum estimated resource consumption you want to allow per statement.

When a statement's estimated consumption exceeds m_value, the statement is rejected and an error is returned. The limit applies to the estimate, not the actual consumption.

Set the limit for a single statement (session level)

Prepend the following command to a specific SQL statement to override the project-level limit for that statement only:

SET odps.sql.metering.value.max=<m_value>;

If this command is omitted, the limit is removed for that statement (no limit applies).

Precedence: A session-level limit takes precedence over the project-level limit. For example, if the project m_value is 100 and a session m_value is 200, the statement is blocked only if its estimated consumption exceeds 200. Statements without a session-level setting are subject to the project limit of 100.

Choose an m_value

To set a meaningful limit, base m_value on your historical SQL consumption:

Download the detailed daily metering report for your project.
Filter for tasks with TaskType = ComputationSql.
Calculate SQL read volume (GB) × SQL complexity for each task.
Identify the highest normal daily consumption and factor in expected business fluctuations.
Set that value as the project-level m_value.

Alternatively, convert your acceptable daily compute cost into an equivalent consumption amount to determine an appropriate m_value.

Set the project-level limit first. Apply session-level limits only for specific statements that genuinely require a higher (or lower) threshold — overusing session-level limits defeats the purpose of the project limit.

Daily cumulative spend limit

This limit caps the total standard SQL spend in a project per calendar day (UTC+8). Only the project owner or a user with the Super_Administrator role can configure it.

Set the limit

SETPROJECT odps.costcontrol.rule={"byDate":{"sql":<Limit>}};

Parameters:

Parameter	Description
`byDate`	Resets at midnight (00:00:00 UTC+8) every day. This is the only supported reset interval.
`Limit`	Maximum daily spend for standard SQL, in USD. Excludes discounts and promotions.

Cost formula for standard SQL:

Cost (USD) = Scanned data volume (GB) × Complexity × 0.0438

In the SAU (Riyadh - Partner Region), the standard SQL billing rate is 0.05256 USD/GB.

How the limit is enforced

Scenario	System behavior
First-time configuration	The system calculates the project's cumulative spend for the current day and uses it as the starting point for limit enforcement. New SQL statements are evaluated against this running total immediately.
Updating an existing limit	The cumulative spend for the current day is not reset. The new limit takes effect immediately and is evaluated against the existing running total.
Limit exceeded	New standard SQL statements are rejected. An error is returned until the daily counter resets at midnight (UTC+8).

Example of updating an existing limit:

Your project has a daily limit of 100 USD. At some point during the day, cumulative spend reaches 99 USD. You raise the limit to 150 USD and then submit a new SQL statement estimated to cost 20 USD.

20 (estimated) + 99 (accumulated) = 119, which is ≤ 150, so the statement runs normally.
If the new statement were estimated at 60 USD instead: 60 + 99 = 159, which exceeds 150, so it is blocked.

Error message

When a statement is blocked, MaxCompute returns an error in this format:

Exceed Cost Limit :
{"AlreadyCost":"100.1","InstanceId":"xxx","Limit":"100","Project":"xxx","TaskType":"SQL","ThisTaskWillCost":"0","TimeWindow":"BYDATE"}

Field	Description
`AlreadyCost`	Cumulative spend for the current day at the time of rejection (USD)
`Limit`	The configured daily limit (USD)
`Project`	The project where the limit was exceeded
`InstanceId`	The SQL instance ID that was rejected
`TaskType`	Task type (`SQL` for standard SQL)
`ThisTaskWillCost`	Estimated cost of the rejected statement (USD)
`TimeWindow`	Reset interval (`BYDATE` means daily)

Set up failure alerts

Because blocked statements cause task failures, configure DataWorks intelligent monitoring to receive failure notifications. This lets your team manually unblock or reschedule critical jobs without waiting until midnight for the daily counter to reset.