Snowflake Query Optimization: Simulate Before You Deploy

Snowflake query optimization is where most Snowflake cost reduction efforts begin — and where many of them stall. The identification phase is genuinely easy: Snowflake's QUERY_HISTORY view provides execution data for every query run in the past year, including credits consumed, bytes scanned, execution time, and the role or user that submitted it. Surfacing the most expensive queries in any Snowflake environment takes about five minutes.

The hard part is what comes next.

Which queries are worth optimizing relative to each other? What will a rewrite actually save — not in a dev environment against 10% of the data, but in production at full scale? Who owns this query, and who has the context to safely rewrite it? Is the production risk of the change worth the estimated credit reduction? And after the change ships, how do you know it worked — and kept working at 90 days?

These questions don't have satisfying answers in most Snowflake environments. Not because the data isn't available, but because the workflow to convert query cost data into confident, documented optimization decisions doesn't exist. This post builds that workflow from identification through to closed, verified resolution.

Step 1: Finding Your Highest-Cost Query Patterns

The first distinction to make before pulling any data: the queries that deserve optimization attention first are not necessarily the slowest or the most credits-per-execution. They are the patterns consuming the most total credits over a defined period — particularly recurring queries that run frequently at elevated cost, rather than one-time analytical queries that incur high cost once and stop.

A query consuming 0.5 credits per execution that runs 800 times per month consumes 400 credits monthly. A one-time analytical query consuming 50 credits runs once. The recurring pattern is the optimization priority — it produces ongoing savings every month the fix holds, not a one-time reduction.

Pull your top recurring query cost patterns:

SELECT
  query_text,
  warehouse_name,
  role_name,
  user_name,
  COUNT(*) AS executions,
  SUM(credits_used_cloud_services) AS total_credits,
  AVG(credits_used_cloud_services) AS avg_credits_per_exec,
  AVG(bytes_scanned) / POWER(1024, 3) AS avg_gb_scanned,
  AVG(execution_time) / 1000 AS avg_exec_seconds,
  AVG(partitions_scanned) AS avg_partitions_scanned,
  AVG(partitions_total) AS avg_partitions_total,
  ROUND(
    100 * AVG(partitions_scanned) /
    NULLIF(AVG(partitions_total), 0), 1
  ) AS avg_partition_scan_pct
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND execution_status = 'SUCCESS'
  AND credits_used_cloud_services > 0
GROUP BY query_text, warehouse_name, role_name, user_name
HAVING COUNT(*) >= 20
ORDER BY total_credits DESC
LIMIT 50

SELECT
  query_text,
  warehouse_name,
  role_name,
  user_name,
  COUNT(*) AS executions,
  SUM(credits_used_cloud_services) AS total_credits,
  AVG(credits_used_cloud_services) AS avg_credits_per_exec,
  AVG(bytes_scanned) / POWER(1024, 3) AS avg_gb_scanned,
  AVG(execution_time) / 1000 AS avg_exec_seconds,
  AVG(partitions_scanned) AS avg_partitions_scanned,
  AVG(partitions_total) AS avg_partitions_total,
  ROUND(
    100 * AVG(partitions_scanned) /
    NULLIF(AVG(partitions_total), 0), 1
  ) AS avg_partition_scan_pct
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND execution_status = 'SUCCESS'
  AND credits_used_cloud_services > 0
GROUP BY query_text, warehouse_name, role_name, user_name
HAVING COUNT(*) >= 20
ORDER BY total_credits DESC
LIMIT 50

SELECT
  query_text,
  warehouse_name,
  role_name,
  user_name,
  COUNT(*) AS executions,
  SUM(credits_used_cloud_services) AS total_credits,
  AVG(credits_used_cloud_services) AS avg_credits_per_exec,
  AVG(bytes_scanned) / POWER(1024, 3) AS avg_gb_scanned,
  AVG(execution_time) / 1000 AS avg_exec_seconds,
  AVG(partitions_scanned) AS avg_partitions_scanned,
  AVG(partitions_total) AS avg_partitions_total,
  ROUND(
    100 * AVG(partitions_scanned) /
    NULLIF(AVG(partitions_total), 0), 1
  ) AS avg_partition_scan_pct
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND execution_status = 'SUCCESS'
  AND credits_used_cloud_services > 0
GROUP BY query_text, warehouse_name, role_name, user_name
HAVING COUNT(*) >= 20
ORDER BY total_credits DESC
LIMIT 50

The avg_partition_scan_pct column is particularly revealing. A query scanning 95% of all partitions on a large table is almost certainly a full table scan candidate — the micro-partition pruning is not working effectively. A query scanning 8% of partitions on the same table is probably well-pruned.

Identify queries with high bytes-scanned-per-credit ratios:

SELECT
  query_id,
  query_text,
  warehouse_name,
  role_name,
  credits_used_cloud_services,
  bytes_scanned / POWER(1024, 3) AS gb_scanned,
  ROUND(
    bytes_scanned / POWER(1024, 3) /
    NULLIF(credits_used_cloud_services, 0), 1
  ) AS gb_per_credit,
  partitions_scanned,
  partitions_total,
  execution_time / 1000 AS exec_seconds
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND bytes_scanned > 0
  AND credits_used_cloud_services > 0.1
ORDER BY credits_used_cloud_services DESC
LIMIT 30

SELECT
  query_id,
  query_text,
  warehouse_name,
  role_name,
  credits_used_cloud_services,
  bytes_scanned / POWER(1024, 3) AS gb_scanned,
  ROUND(
    bytes_scanned / POWER(1024, 3) /
    NULLIF(credits_used_cloud_services, 0), 1
  ) AS gb_per_credit,
  partitions_scanned,
  partitions_total,
  execution_time / 1000 AS exec_seconds
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND bytes_scanned > 0
  AND credits_used_cloud_services > 0.1
ORDER BY credits_used_cloud_services DESC
LIMIT 30

SELECT
  query_id,
  query_text,
  warehouse_name,
  role_name,
  credits_used_cloud_services,
  bytes_scanned / POWER(1024, 3) AS gb_scanned,
  ROUND(
    bytes_scanned / POWER(1024, 3) /
    NULLIF(credits_used_cloud_services, 0), 1
  ) AS gb_per_credit,
  partitions_scanned,
  partitions_total,
  execution_time / 1000 AS exec_seconds
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND bytes_scanned > 0
  AND credits_used_cloud_services > 0.1
ORDER BY credits_used_cloud_services DESC
LIMIT 30

High gb_per_credit ratios on large queries often indicate clustering key misalignment — the query is scanning far more data than the result set requires because Snowflake can't prune micro-partitions effectively.

Step 2: Diagnosing the Anti-Patterns Generating the Most Waste

Once the highest-cost candidates are identified, the next step is diagnosing which specific anti-pattern is generating the waste. The fix strategy differs significantly depending on the root cause.

Anti-Pattern 1: Full Table Scans from Ineffective Partition Pruning

Snowflake's micro-partition architecture prunes data aggressively when filter predicates align with the physical clustering of the data. When they don't — or when the filter condition is written in a way that prevents pruning — the query scans the entire table regardless of how selective the result set is.

The most common causes of ineffective partition pruning:

Wrapping filter columns in functions — WHERE YEAR(created_at) = 2025 prevents Snowflake from using created_at values stored in micro-partition metadata to prune. The function is evaluated per row rather than per partition. The fix: WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01'.

Using non-selective lead predicates — filtering on a column with very low cardinality (e.g., status = 'active' on a table where 80% of rows are active) does not prune meaningfully. Combine with a high-cardinality column filter to enable effective pruning.

Mismatched clustering keys — a table clustered on customer_id being filtered primarily on created_date. The clustering key was chosen for a different access pattern than the current query. Fix: either re-cluster the table on created_date for this access pattern, or add a secondary clustering strategy.

Implicit type conversions in join conditions — joining a VARCHAR column to an INTEGER column causes an implicit cast that disables pruning. Explicit casting in the filter is required.

To identify partition scan efficiency for a specific query, use Snowflake's QUERY_HISTORY with partition columns:

SELECT
  query_id,
  partitions_scanned,
  partitions_total,
  ROUND(100 * partitions_scanned / NULLIF(partitions_total, 0), 1)
    AS scan_pct,
  bytes_scanned / POWER(1024, 3) AS gb_scanned
FROM snowflake.account_usage.query_history
WHERE query_id = '<your_query_id>'

SELECT
  query_id,
  partitions_scanned,
  partitions_total,
  ROUND(100 * partitions_scanned / NULLIF(partitions_total, 0), 1)
    AS scan_pct,
  bytes_scanned / POWER(1024, 3) AS gb_scanned
FROM snowflake.account_usage.query_history
WHERE query_id = '<your_query_id>'

SELECT
  query_id,
  partitions_scanned,
  partitions_total,
  ROUND(100 * partitions_scanned / NULLIF(partitions_total, 0), 1)
    AS scan_pct,
  bytes_scanned / POWER(1024, 3) AS gb_scanned
FROM snowflake.account_usage.query_history
WHERE query_id = '<your_query_id>'

A scan_pct above 80% on a table with more than 1,000 partitions is a strong signal that partition pruning is not working effectively.

Anti-Pattern 2: SELECT * on Wide Tables

Snowflake's columnar storage means that every column selected adds to the bytes scanned — even columns that the downstream business logic never uses. SELECT * on a table with 200 columns where the application uses 12 of them is scanning approximately 16x more data than necessary.

The fix is explicit column selection in every query. The organizational challenge is that SELECT * is deeply embedded in the habits of analysts and in auto-generated queries from BI tools and ORM layers. Identifying which queries use SELECT * at scale:

SELECT
  query_text,
  COUNT(*) AS executions,
  SUM(credits_used_cloud_services) AS total_credits,
  SUM(bytes_scanned) / POWER(1024, 3) AS total_gb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_text ILIKE '%SELECT *%'
  AND query_type = 'SELECT'
GROUP BY query_text
ORDER BY total_credits DESC
LIMIT 20

SELECT
  query_text,
  COUNT(*) AS executions,
  SUM(credits_used_cloud_services) AS total_credits,
  SUM(bytes_scanned) / POWER(1024, 3) AS total_gb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_text ILIKE '%SELECT *%'
  AND query_type = 'SELECT'
GROUP BY query_text
ORDER BY total_credits DESC
LIMIT 20

SELECT
  query_text,
  COUNT(*) AS executions,
  SUM(credits_used_cloud_services) AS total_credits,
  SUM(bytes_scanned) / POWER(1024, 3) AS total_gb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND query_text ILIKE '%SELECT *%'
  AND query_type = 'SELECT'
GROUP BY query_text
ORDER BY total_credits DESC
LIMIT 20

For queries generated by BI tools or ETL frameworks, the fix often requires configuration changes at the tool level rather than SQL rewrites — pushing the optimization task to the team responsible for the BI or pipeline configuration.

Anti-Pattern 3: Repeated Computation in CTEs or Subqueries

SQL patterns that recalculate the same expensive result set multiple times within a single query — either through multiple CTE references or through correlated subqueries — force Snowflake to execute the computation repeatedly. Materializing the intermediate result using a temporary table or a pre-computed stage eliminates the redundant work.

The signature of this anti-pattern in query execution profiles is high bytes processed relative to bytes scanned — the query is processing data that was already computed rather than reading fresh from storage.

Anti-Pattern 4: Missing Statement Timeout Limits

Queries without STATEMENT_TIMEOUT_IN_SECONDS configured can run indefinitely in the event of a logic error, an accidental cross join, or an unusually large data volume. A single runaway query can consume thousands of credits before anyone notices — because the alert threshold is typically set on warehouse-level spend rather than individual query duration.

Set statement timeouts at the warehouse level as a default guardrail:

ALTER WAREHOUSE <warehouse_name>
SET STATEMENT_TIMEOUT_IN_SECONDS = 3600; -- 1 hour maximum

ALTER WAREHOUSE <warehouse_name>
SET STATEMENT_TIMEOUT_IN_SECONDS = 3600; -- 1 hour maximum

ALTER WAREHOUSE <warehouse_name>
SET STATEMENT_TIMEOUT_IN_SECONDS = 3600; -- 1 hour maximum

For development warehouses where ad-hoc queries may run long:

ALTER WAREHOUSE <dev_warehouse_name>
SET STATEMENT_TIMEOUT_IN_SECONDS = 1800; -- 30 minutes

ALTER WAREHOUSE <dev_warehouse_name>
SET STATEMENT_TIMEOUT_IN_SECONDS = 1800; -- 30 minutes

ALTER WAREHOUSE <dev_warehouse_name>
SET STATEMENT_TIMEOUT_IN_SECONDS = 1800; -- 30 minutes

Step 3: The Simulation Gap — Why Teams Avoid the Hard Optimizations

Once high-cost query patterns are identified and the anti-pattern is diagnosed, the optimization path seems clear. In practice, a significant proportion of identified query improvements never get deployed — not because engineers can't write the fix, but because they can't confidently estimate what it will save or what it might break.

The standard approach to query optimization is to rewrite in development, test against a representative dataset, and deploy to production. This has two specific failure modes:

Development environment fidelity — most development environments don't reflect production data volumes, partition distributions, or concurrent query patterns. A query rewrite that appears to save 70% of execution time against a 10-million-row development table may produce different results against a 4-billion-row production table with a different clustering key profile. The savings estimate from dev testing is directionally useful but not reliable enough to use as a prioritization decision or a stakeholder commitment.

Production risk without a pre-deployment estimate — when the savings are unknown in advance, the optimization competes for engineering time against work whose value is clearly defined. A feature delivery has a defined scope and stakeholder expectation. A query optimization has "it should save some credits" and a production deployment risk. Under normal engineering prioritization, the feature wins.

Pre-deployment simulation addresses both failure modes by modeling the expected credit impact of a proposed query change against actual production workload data — not dev environment data — before any change is applied. The simulation produces three outputs:

Expected credit savings per month — modeled against the actual execution frequency and data volume from the past 30 days of production query history. If the query ran 840 times in the past 30 days at an average of 0.4 credits per execution, and the rewrite is estimated to reduce per-execution cost by 65%, the monthly savings estimate is 840 × 0.4 × 0.65 = 218 credits per month, at current execution frequency.

Expected execution time change — the performance impact of the rewrite modeled against actual production data volumes. This gives the engineer confidence that the optimization doesn't create latency problems for downstream consumers of the query result.

Simulation-to-actual benchmark — after deployment, the simulation estimate becomes the measurement baseline. Actual savings within 20% of the estimate confirm the model is well-calibrated. Variance above 30% triggers an investigation — either the implementation was incomplete, the workload behavior changed between the simulation period and deployment, or the simulation model needs recalibration for this query pattern type.

The organizational effect of simulation is as important as the technical effect. When an engineer can show their manager that a specific query rewrite will save 218 credits per month — before writing a line of production code — the optimization gets prioritized. When the only evidence is "this query looks expensive in the query history," it competes with every other demand on engineering time and loses.

Step 4: Attribution and Routing — Who Actually Owns This Query

A significant proportion of expensive Snowflake queries are not owned by the team that identified them. BI dashboards generate queries on behalf of analysts who aren't aware of the execution cost. ETL pipelines run queries written by engineers who changed teams or left the organization. Scheduled reports execute query patterns written under different data volume assumptions two years ago.

Before a query optimization can be executed, it needs a clear owner — the person or team with the context to understand the query's business purpose, its downstream dependencies, and the risk profile of any proposed change.

Identify query ownership from execution metadata:

SELECT
  q.query_text,
  q.role_name,
  q.user_name,
  q.warehouse_name,
  -- Client application if available
  q.query_tag,
  COUNT(*) AS executions,
  SUM(q.credits_used_cloud_services) AS total_credits
FROM snowflake.account_usage.query_history q
WHERE q.start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND q.query_id IN (
    -- Paste your top query IDs from the identification step
    '<query_id_1>', '<query_id_2>', '<query_id_3>'
  )
GROUP BY
  q.query_text, q.role_name, q.user_name,
  q.warehouse_name, q.query_tag
ORDER BY total_credits DESC

SELECT
  q.query_text,
  q.role_name,
  q.user_name,
  q.warehouse_name,
  -- Client application if available
  q.query_tag,
  COUNT(*) AS executions,
  SUM(q.credits_used_cloud_services) AS total_credits
FROM snowflake.account_usage.query_history q
WHERE q.start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND q.query_id IN (
    -- Paste your top query IDs from the identification step
    '<query_id_1>', '<query_id_2>', '<query_id_3>'
  )
GROUP BY
  q.query_text, q.role_name, q.user_name,
  q.warehouse_name, q.query_tag
ORDER BY total_credits DESC

SELECT
  q.query_text,
  q.role_name,
  q.user_name,
  q.warehouse_name,
  -- Client application if available
  q.query_tag,
  COUNT(*) AS executions,
  SUM(q.credits_used_cloud_services) AS total_credits
FROM snowflake.account_usage.query_history q
WHERE q.start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND q.query_id IN (
    -- Paste your top query IDs from the identification step
    '<query_id_1>', '<query_id_2>', '<query_id_3>'
  )
GROUP BY
  q.query_text, q.role_name, q.user_name,
  q.warehouse_name, q.query_tag
ORDER BY total_credits DESC

The role_name column typically maps to a team or functional group. The user_name identifies the specific individual or service account. The query_tag — if your engineering teams have adopted query tagging — provides explicit attribution to a pipeline, data product, or application.

Cross-referencing role_name against your organizational role structure converts anonymous query execution data into attributed workload ownership. The team associated with the role that submitted the query is the routing target for the optimization task.

When ownership is genuinely ambiguous — multiple teams sharing a warehouse role, or a service account shared across pipelines — the routing target is the platform or data engineering team responsible for the shared infrastructure, with a request to determine the correct business owner before proceeding.

Step 5: The 7-Step Query Optimization Workflow That Actually Closes

With identification, diagnosis, simulation, and attribution in place, the optimization workflow has all the inputs it needs to run systematically rather than opportunistically.

Step 1 — Pull the top 50 recurring credit-consuming queries from QUERY_HISTORY for the past 30 days using the identification query above. Filter for queries with at least 20 executions to exclude one-time analytical runs.

Step 2 — Attribute each query to an owning team using role, user, and query_tag metadata. Flag any query where ownership is ambiguous for a separate resolution step before proceeding.

Step 3 — Score each query by optimization potential. Use three signals: partition scan percentage (high = full scan candidate), average GB scanned per credit (high = column selection or clustering inefficiency), and execution frequency (high = high monthly impact from even modest per-execution savings).

Step 4 — Select the top 10 candidates by combined optimization potential and business impact. These are the queries that get the simulation treatment before anything else is touched.

Step 5 — For each top-10 candidate, simulate the credit impact of the proposed rewrite against production workload data. Document the estimated monthly savings, the estimated execution time change, and any identified downstream dependencies that the change might affect.

Step 6 — Route each optimization task to the owning team with the simulation results, the anti-pattern diagnosis, and a recommended fix approach. The routing communication should include: what the query is costing today, what the simulation estimates the fix will save, what the fix involves at a high level, and what the expected performance impact is.

Step 7 — Track post-deployment credit consumption at 30 and 90 days against the pre-optimization baseline and the simulation estimate. Flag any query whose post-optimization cost trends upward for re-investigation. Document the outcome — actual savings, variance from simulation estimate, root cause of any variance — in a form that informs future optimization decisions for similar patterns.

This workflow converts a list of expensive queries into a closed, documented optimization record — not a backlog item that sits indefinitely because nobody owns the next step.

Why Query Optimization Regresses at 90 Days

Query optimization has a persistence problem that most teams discover at the quarterly bill review rather than preventing continuously. The specific patterns that cause query optimization gains to reverse:

New pipeline versions reproducing old anti-patterns — a query gets optimized, the fix is documented in a ticket, the ticket gets closed. Six months later, a new version of the same pipeline is written by a different engineer. The optimization history wasn't accessible or visible during development, and the new version implements the same full table scan or SELECT * pattern that was fixed previously.

Schema evolution breaking clustering alignment — a table is re-clustered or the schema is modified in a way that changes the partition distribution. A query that was pruning to 8% of partitions after optimization starts scanning 70% of partitions again because the clustering key no longer aligns with the filter predicate.

Increased execution frequency amplifying per-execution cost — a query that was optimized for twice-daily execution gets promoted to hourly execution to support a real-time dashboard. The per-execution credit cost is unchanged from the optimization, but the monthly total triples. The query returns to the top of the cost list without any anti-pattern regression.

The 90-day checkpoint catches these patterns before they compound into significant cost increases. The key is treating the checkpoint as a mandatory workflow step — running the identification query again after 90 days specifically for previously closed optimizations and comparing current credit consumption against the post-optimization baseline.

Frequently asked questions

How do I find the most expensive Snowflake queries?

Query QUERY_HISTORY in Snowflake's account usage schema, filtering for SELECT queries with at least 20 executions in the past 30 days, ordered by total credits consumed. Prioritize recurring queries over one-time analytical runs — a query executing 800 times monthly at 0.5 credits each has 3x the monthly impact of a one-time query consuming 100 credits.

What causes Snowflake queries to consume too many credits?

The four most common causes are: full table scans from ineffective partition pruning (often caused by wrapping filter columns in functions or mismatched clustering keys), SELECT * on wide tables scanning unnecessary columns, repeated computation in CTEs or subqueries that could be materialized once, and missing statement timeout limits that allow runaway queries to consume credits indefinitely.

How do I tell if a Snowflake query is doing a full table scan?

Check the partitions_scanned and partitions_total columns in QUERY_HISTORY for the specific query_id. A scan percentage above 80% on a table with more than 1,000 partitions is a strong indicator that partition pruning is not working effectively. The fix depends on the root cause — function wrapping, clustering key misalignment, or non-selective filter predicates.

What is pre-deployment simulation for Snowflake query optimization?

Pre-deployment simulation models the expected credit savings and execution time impact of a proposed query rewrite against actual production workload data — not dev environment estimates — before any change is deployed. It produces a monthly savings estimate, a performance impact estimate, and a benchmark against which post-deployment results are measured. Simulation unlocks harder optimizations by replacing production risk with an evidence-based tradeoff assessment.

Why do Snowflake query optimizations stop working over time?

Three patterns cause query optimizations to regress: new pipeline versions written by different engineers reproduce the same anti-patterns because the optimization history wasn't visible during development; schema evolution breaks clustering key alignment that the optimization depended on; and increased query execution frequency amplifies the per-execution cost even though the query itself is unchanged. 90-day enforcement checkpoints catch all three patterns before they compound.

How do I identify who owns an expensive Snowflake query?

Use the role_name, user_name, and query_tag columns in QUERY_HISTORY for the specific query_id. The role_name typically maps to a functional team in your organizational role structure. The query_tag — if your teams have adopted query tagging — provides explicit attribution to a pipeline, data product, or application. Cross-reference with your Snowflake role hierarchy to identify the responsible team.

What should a Snowflake query optimization workflow include?

A complete query optimization workflow covers seven steps: identify top recurring credit consumers from QUERY_HISTORY; attribute each to an owning team using role and user metadata; score by optimization potential using partition scan percentage and bytes-per-credit ratios; select top candidates for simulation; simulate the credit and performance impact of the proposed fix; route the optimization task to the owning team with simulation results; and track post-deployment credit consumption at 30 and 90 days.