Auto-suspend at 60 seconds: the setting most Snowflake accounts get wrong

If you’re a CFO, this single setting — sitting on every warehouse in your account — decides how much of your Snowflake bill is compute you actually used versus compute that sat idle. If you run the platform, there’s a 20-minute check at the end you can do today.

First, how Snowflake actually charges you

Snowflake bills a running warehouse per second — but only after the first 60 seconds. That first minute is a flat charge either way: run a warehouse for 5 seconds or 55 seconds, and you pay for the full minute.

The part that catches teams out is what happens on restart. The 60-second minimum doesn’t carry over — it applies again every time the warehouse resumes. Snowflake’s documentation spells this out with a worked example: a warehouse that runs 61 seconds, suspends, then restarts and runs for under a minute is billed for 121 seconds — 60 + 1 + 60.

So a warehouse that keeps dozing off and waking up isn’t saving you what it feels like it should. You pay that minimum again on every wake-up.

So why 60 seconds, and not something else?

Worth being precise here, because this gets repeated as a rule when it isn’t one. Snowflake’s own guidance is to keep auto-suspend low — its wording is 5 or 10 minutes or less. That’s a range with room in it, and 60 seconds sits inside it rather than contradicting it.

We point most teams toward the short end because most of the warehouses we see run dashboards and scheduled jobs — workloads with genuinely long quiet stretches, often hours. For that shape of work, a short auto-suspend is a clear win.

But if a warehouse gets a query every couple of minutes like clockwork, 60 seconds backfires. It suspends and resumes all day, and each resume restarts the minimum charge. Letting it stay awake can genuinely cost less. The right answer depends on your query gaps — which is why the next section is about measuring rather than guessing.

It’s not only cost — suspending drops the cache

There’s a second effect, and it shows up as speed rather than spend. When a warehouse suspends, it drops its local cache. Snowflake notes this directly: the cache is dropped on suspend, which can make the first queries slower after it resumes, until the cache warms up again.

If your team already grumbles that “the dashboard feels slow sometimes”, an aggressive auto-suspend is one of the first things worth ruling out. That complaint and this setting are connected more often than people expect.

Don’t guess — go and look

You don’t have to reason about the right number in the abstract. Your account already has the answer.

What to do this week

1. Look up the auto-suspend value on your five most expensive warehouses. Most teams haven’t touched it since the warehouse was created.
2. Check the real query gaps on each one in QUERY_HISTORY.
3. Long quiet stretches? Bring auto-suspend down toward 60 seconds and watch the effect over a week.
4. Short, frequent gaps? Go longer instead of shorter, and compare.
5. Slowness right after a wake-up is a signal to loosen the setting, not tighten it.

One last thing worth saying out loud: this isn’t a set-and-forget fix. Dashboards get added, jobs get rescheduled, teams change how they work. The reason this setting drifts wrong in the first place is that nobody goes back to it — so put a date in the calendar, not just a value on the warehouse.

Auto-suspend is one of eight patterns we see behind growing Snowflake bills — the rest are in 8 reasons your Snowflake bill keeps growing. If your problem is queries queuing rather than warehouses idling, start with multi-cluster vs. a bigger warehouse instead.