Snowflake Metrics Digest

Somebody on your team resumes the warehouse most mornings to look at the same three numbers, and every one of those check ins spends credits. This agent does that run once, at 08:00: your statements in order, results collected as each one finishes, then a single Slack digest with the change since yesterday and any statement that failed quoted in Snowflake's own words. It submits nothing outside your list and never retries, so the warehouse wakes up once a day for a cost you can predict.

What people use it for

• One warehouse wake up a day - Rather than five people resuming a warehouse at five different times for five different numbers, the list runs once and everyone reads the same message. The credits go into a single window you can size.
• Metrics without a BI seat - Finance, support and founders read the digest in Slack. Nobody needs a Snowflake login, a role grant, or a reporting licence to see how yesterday went.
• A failed statement is news - When a view gets replaced or a grant is revoked, the digest names the statement and quotes the error the same morning. A silent hole in a dashboard can go unnoticed for weeks.
• Rows stay in the warehouse - Aggregates land in Slack and raw result rows do not, so what you put in the statement list is exactly what a channel can ever see. That matters when the tables underneath hold customer or patient records.

Before you fork

Which role and warehouse should I point it at?

Make a dedicated role with SELECT on just the views your statements read and USAGE on a small warehouse, an extra small one with a short auto suspend is plenty. Connect that role, add the Slack channel, and write your statements out with the database and schema fully qualified, because the agent never issues a USE DATABASE to fill in a gap.

How many credits will this burn?

An extra small warehouse costs one credit per hour, so a two minute morning run is roughly a thirtieth of a credit and a full month of digests lands near one credit, plus whatever your heaviest statement makes the warehouse work for. It never retries, so a broken statement costs a single attempt. Keeping the list to statements that return in seconds is what keeps that number small.

Could customer data end up in a Slack channel?

Only if your statements return it. The agent is told to post the aggregates the digest style asks for and never to paste raw result rows, so a statement that counts orders puts a count in Slack. A statement that selects a hundred customer rows is a hundred customer rows sitting in a channel, which is a reason to write aggregates into the list rather than to rely on the instruction. Masking policies on the role you connect apply as normal.