Cost limits

A per-query byte limit stops a single expensive statement before it runs, and daily, weekly, or monthly budgets cap how much a person or an organization can scan in a period. Both work from BigQuery's dry-run estimate, so the check happens before anything is billed. On a reservation, where you pay for slot time rather than bytes, a slot limit per query cancels a query that uses more than you allowed. A time limit per query is enforced by BigQuery itself, while the query runs.

Per-query limit

Every query is dry-run before it executes. If the bytes it would scan exceed the tab’s limit, it doesn’t run; you get the warning above instead.

• Cancel takes you back to the editor. Nothing runs.
• Maybe it’ll fit runs with the limit unchanged. Dry-run estimates are an upper bound; if the query really does bill more than the limit, BigQuery rejects it and you pay nothing.
• Run once runs with a temporarily higher limit, this time only.
• Update limit & run raises the limit for this tab and runs.

The limit is per tab. The default for new tabs is 100 GB; click the ⚙ at the left of the editor’s status bar to change it for the tab you’re in:

Slot limit per query

On a reservation you pay for slot time, not bytes, so a byte limit meters the wrong thing. A compute-heavy query over a small table can burn the reservation while every byte control stays green; a scan-heavy query can eat the GB budget while costing almost nothing in slots.

The slot limit is the control for that. Querylab.io watches the slot time BigQuery reports while the query runs, and cancels the query once a reading passes your limit.

Anything from 0.01 to 100,000 slot-hours is accepted. Leave it empty for no limit. New tabs start with the account default from Settings → Limits & Costs, the same way Max GB billed does, so changing the default never re-limits a tab you already have open.

On a tab billed for slot time the slot limit leads the popover and the byte limits fold under it, behind a row that names the byte limit still in force. They fold rather than disappear because BigQuery enforces the byte limit on a reservation job too: it refuses the query at submit, and a limit that refuses queries has to be a limit you can find. One click opens them.

The two slot fields are one limit, like Max GB billed and Max query price: type slot-hours and the price follows, type a price and the slot-hours follow. The conversion uses your reservation’s own rate, for its edition and your organization’s commitment tier and discount, which is the same rate the live slot cost in the status bar is priced at. What one more query really adds to the bill still depends on whether it runs inside capacity you have already paid for, so read the price as what that much slot time is worth, not as what this query will cost you. A reservation whose edition Querylab.io cannot see has no rate, and then the limit stands on its own in slot-hours.

How approximate it is

This is the one limit in the app that the app itself enforces, and the honest description of it is a cancel that arrives late:

• BigQuery has no slot limit per query. A reservation’s max_slots caps every query running in it together, and scheduling_policy_max_slots on an assignment caps one project’s share of that. Neither caps a single query, so there is nothing to hand BigQuery.
• The reading is published about every 30 seconds. We measured one timeline sample per ~30 s, so between publishes the same figure ages: it was 3.7 to 34 seconds stale, and mid-run it under-reported a job’s real slot time by up to 8x. Polling faster buys nothing, because there is nothing new to read.
• So a query goes over before it is seen to. By the time a reading shows the limit passed, the query has used more than the reading says, and BigQuery bills all of it. The cancel stops the query from spending more; it does not refund what it spent.
• A query shorter than about five seconds is never measured at all. The first reading of a job arrived between 3.7 and 9.2 seconds in, so a fast query finishes before the limit can look at it.
• It only works while Querylab.io is open. Closing the tab or quitting the app stops the watching. For a limit that survives that, use the time limit below, which BigQuery enforces.
• A multi-statement script is not watched at all. A script’s parent job reports no slot time until it finishes, and reports an empty timeline the whole way through, so there is never a reading to act on. A script is covered by the time limit below and by nothing here.
• A cancel can fail. If BigQuery refuses the cancel twice, the query is left running and this app stops watching it. You are told so, with where to stop it.

The status bar shows the live reading against your limit while the query runs, with the same caveat in its tooltip:

When the limit does fire, the query fails with what it cost:

Query cancelled. It used about 0.52 slot-hours and the limit was 0.50.
You are charged for the slot time it used.

What carries it

Queries from a query tab, when the query really is billed for slot time. A tab pinned to on-demand carries no slot limit even if one is set: on-demand bills bytes, so cancelling such a query would cost you the results and save you nothing. A tab routed to a reservation carries it even when the project itself is on-demand. Reconnecting to a job that is already running does not: it was started elsewhere, under whatever limit applied then.

The field is still offered when Querylab.io cannot tell how a project is billed, because hiding it would leave someone on a reservation unable to set a limit at all. It says so under the field in that case, and the limit is not applied to a query it cannot place.

Notebook cells. A notebook has its own Slot limit per query field in the notebook settings, and a cell can set its own in the cell settings. A cell with no field of its own uses the notebook’s, and a notebook with none uses the account default from Settings → Limits & Costs. Unlike a tab, a notebook reads the account default each time a cell runs. A cell or a notebook that legitimately runs for hours can set a higher limit of its own. An empty field follows the level above it: the notebook, then your default. A cell routed to on-demand carries no slot limit, as for a tab.

AI tools. They have their own field in Settings → MCP, and use the account default when it is empty.

Time limit per query

A byte limit is a decision taken before the query starts. A time limit runs with the query: Querylab.io sends it to BigQuery as part of the request, and BigQuery stops the job when it expires. That makes it the only limit on this page that is still acting after you close the tab, quit the app, or lose the network.

It is one setting for the account, in Settings → Limits & Costs → Single Query Limit, and every query you run, from a query tab, a notebook cell or an AI tool, uses it. Unlike the byte limit there is no per-tab field: a deadline is a safety net you set once, and a field in the tab popover would be clutter.

Anything from 10 seconds to 6 hours is accepted. Leave it empty for no limit. BigQuery fails every query at 6 hours of its own accord, so a longer limit would never fire.

When it fires

BigQuery checks the deadline every so often rather than at the second, so the stop lands late. We measured limits of 10, 15 and 30 seconds against a query that would otherwise have run for minutes: the jobs were stopped after 25, 31 and 40 seconds of run time, an overshoot of 10 to 16 seconds. The query then fails with:

Job execution was cancelled: Job timed out after 10 sec

The 10-second floor comes from the same measurements. Below it the limit stops being a limit: jobs that ran 6.8 seconds finished untouched under limits of 2, 4, 5 and 8 seconds, and a sub-second limit fails the request outright, with no job to show for it.

What it caps, and what it doesn’t

It caps how long a query runs. It is not a cost ceiling. Everything the query used before it stopped is billed, the overshoot included, so no amount of money follows from the number you set here. For a figure you can hold BigQuery to, use the byte limit above.

It is not a slot limit either, and it cannot be converted into one. A time limit bounds the time; what that time costs in slots depends on how many slots the query was given, which for a reservation that can borrow idle slots is not a number anyone can state in advance. The query also keeps spending through the overshoot. For a limit on slot time, use the slot limit above and read what it says about itself; the two work together, and a time limit is the half that keeps working when the app is closed.

What carries it

Query tabs, notebook cells and AI tools. They all use the one account setting. AI tools also have their own caps in Settings → MCP → Access limits; see Local MCP server.

Capping spend per day, week, or month

A budget caps the total bytes you can scan in a day, a week, or a month. A query that would cross the remaining budget stops before BigQuery bills it. Set them in Settings → Limits & Costs → BigQuery Limits; the same section holds the default per-query limit for new tabs.

What gets estimated

The cost shown in the editor is BigQuery’s own dry-run estimate, so it covers everything the dry-run covers, including CREATE TABLE … AS SELECT.

CREATE TEMP TABLE AS SELECT

CREATE TEMP TABLE … AS SELECT is estimated from its SELECT:

CREATE TEMP TABLE daily_metrics AS
SELECT user_id, COUNT(*) AS actions
FROM `ace-analytics.warehouse.events`
WHERE event_date = CURRENT_DATE()
GROUP BY user_id;

What the limits cover

All four cover queries run from Querylab.io and nothing else: scheduled queries and anything run outside the app are untouched by them. They differ in what happens next, which is what decides how much you can trust each one: