BigQuery Metrics Digest with Claude Code
Run each query character for character, in the order given. Do not widen a date range, do not drop a LIMIT, do not add a column. That is an odd thing to ask of a harness whose instinct is to understand a failure and repair it, and it is what keeps your scan bill predictable. Claude Code follows explicit written constraints closely, including the constraint not to be helpful.
Watch it work before it's live
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
Morning metrics 12 August
All seven queries returned inside nine seconds. Daily active users came back at 41,208 against 39,940 yesterday, checkout conversion at 2.31 percent against 2.44, new paid signups at 186, and refunds at 12,340.55 BRL. The events query scanned 84 GB, in line with every other morning this month.
Set up in minutes
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect Google BigQuery
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Metrics queries
The exact SELECT statements to run each morning, each with the name it should carry in the digest. Include the partition filter every table needs, because the agent adds nothing to what you write, and this list is the only SQL it will ever run.
Digest style
How the digest should read - which metric leads, what counts as an outlier worth flagging (checkout conversion under 2 percent, refunds above 5,000), and who to tag when a query fails.
Runs on Claude Code
Preselected for this page — connect your Claude Code account during setup, or switch to NoClick's built-in models with one click.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
Why Claude Code for this agent
No SQL of its own
Your list is the whole scope. Table listing exists only to confirm a name after a failure, never to look around the warehouse beforehand.
A failure is reported, not solved
The broken query gets its line, the error verbatim, and the owner tagged. Debugging it is a person's job, done by somebody who knows what that table costs to touch.
Before you fork
Will it try to fix a query that failed?
No, and that is deliberate. It reports the failure in BigQuery's own words and moves on, because a rewritten or retried query is another billed scan against a table somebody chose carefully. The downside is real: a query broken for a week is reported every morning and stays broken until a person acts.
Run it with a different agent
Put BigQuery Metrics Digest to work on Claude Code
Free to start. Guided setup, a test run against staged conversations, and it's live.