Snowflake Warehouse Credit Consumption and Cost Guard Sentinel

Snowflake virtual warehouses scale elastically, making runaway queries easy to overlook until the monthly invoice arrives. This sentinel queries SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY every 15 minutes, aggregates credit consumption per warehouse over the last 24 hours, and dispatches a formatted Slack alert the moment any warehouse breaks through the configured ceiling.

How it works

1. query_warehouse_credits (io.kestra.plugin.jdbc.snowflake.Query) connects to Snowflake over JDBC and fetches the top 10 warehouses by CREDITS_USED across the last 24 hours, including compute versus cloud-services breakdown.
2. check_threshold (io.kestra.plugin.core.flow.If) evaluates whether any returned row has TOTAL_CREDITS_USED greater than inputs.credit_threshold.
   • then, alert_slack (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) fires a rich Slack message listing every offending warehouse with its credit total.
   • else, log_ok (io.kestra.plugin.core.log.Log) records a clean-bill-of-health entry in the execution log.
3. The errors block fires a Slack alert if the Snowflake JDBC call itself fails (bad credentials, network timeout, permission denied on the view).
4. A Schedule trigger fires every 15 minutes and ships disabled so you can verify the flow before enabling continuous monitoring.

What you get

• Automated 15-minute credit consumption polling across all active Snowflake warehouses.
• Conditional Slack alerts naming every warehouse that breached the threshold, with compute and cloud-services credit split.
• Full execution history in Kestra for auditability and trend review.
• A safe, disabled trigger that you enable only when ready.

Who it's for

• FinOps engineers and data platform leads who need proactive Snowflake cost governance.
• Analytics engineers responsible for overnight dbt runs or large ELT pipelines that can spike credit consumption.
• DevOps and SRE teams with shared Snowflake accounts across multiple teams.

Why orchestrate this with Kestra

Snowflake Tasks can schedule SQL but cannot evaluate results, branch on conditions, or fire webhooks. Kestra wraps the entire pipeline, JDBC query, conditional branching, Slack alerting, and failure recovery, in a single declarative YAML flow stored in Git. Secrets stay in the Kestra secret store; nothing is hardcoded. Execution history, logs, and outputs are always visible in the Kestra UI.

Prerequisites

• A Snowflake account with a user that has SELECT on SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY.
• A Slack incoming webhook for the alerting channel.

Secrets

• SNOWFLAKE_PASSWORD: Password for the Snowflake user specified in inputs.username.
• SLACK_WEBHOOK: Slack incoming webhook URL.

Quick start

1. Add SNOWFLAKE_PASSWORD and SLACK_WEBHOOK to your Kestra namespace secrets.
2. Import this blueprint and fill in account, username, and optionally credit_threshold.
3. Execute manually to confirm the JDBC connection and verify the query returns rows.
4. Enable the Schedule trigger for continuous 15-minute monitoring.

How to extend

• Add io.kestra.plugin.github.issues.Create in the then branch to open a FinOps tracking ticket automatically.
• Persist credit rows to a postgres or bigquery table for long-term trend dashboards.
• Replace the schedule with a Webhook trigger to evaluate on-demand after a large batch job completes.
• Scope the query to a specific WAREHOUSE_NAME by adding a WHERE clause and an additional input.

Links

• Kestra Snowflake Plugin
• Snowflake WAREHOUSE_METERING_HISTORY
• Kestra Slack Plugin
• Kestra If Task