Every data team has a few of these: a job that got scheduled to run every hour, “just to be safe,” back when someone wasn’t sure how often the table actually needed refreshing. Nobody sat down and decided to overspend – it was the safe default, the reasonable call at the time. And it still looks that way today, because nothing about it ever broke.
That’s exactly the problem. None of these decisions were wrong on their own. But most data teams have plenty of them – scattered across different pipelines, set up by different people, at different times, each one too small on its own to be worth anyone’s afternoon to go check. Add them up, though, and that’s a real, ongoing slice of your Snowflake budget going toward refreshes nobody’s actually looking at.
That’s not where you want your budget going
Every team we talk to has something they’d rather be spending on: the next model, the feature customers are asking for, the extra headcount that’s been on hold. None of those get easier to justify because a handful of forgotten jobs are quietly running in the background. If anything, it’s the opposite – budget that’s visibly going toward waste is the first thing that gets questioned when anyone starts asking where the data spend is going. Freeing it up isn’t just about the dollar amount; it’s about being able to point at your spend and say “this is all going somewhere that matters.”
And it’s not just about the money
A job that runs far more often than it needs to isn’t only costing you compute – it’s also making your pipeline a little harder to trust. A table that updates every hour looks important, even when it isn’t, and anyone glancing at your system has no way of knowing which is which. It’s one more thing that can fail overnight for no good reason, one more alert someone has to chase down, one more piece of clutter in a system that’s already complicated enough without it. Cleaning these up isn’t just a cost exercise – it’s tidying up the picture of what’s actually going on in your pipeline.
Why this is so hard to catch on your own
The honest reason these jobs survive for years isn’t laziness – it’s that nobody can see the full picture. You’d need to know, for every table, how often it’s written to and how often anyone actually uses it, and then trace that back to the specific job responsible, across a pipeline nobody holds entirely in their head. That’s not a weekly audit anyone has time for, so it just doesn’t happen, and the “just in case” jobs keep running.
This is exactly what Seemore was built to catch
Seemore’s Frequency Optimization does this automatically: it finds the tables being refreshed far more often than anyone’s checking them, traces the exact job behind it through your pipeline’s own lineage, and tells you precisely what it’s costing you. No manual audit, no guessing which job is safe to touch – just a clear, specific thing to fix, with the number attached to make it worth your while.
Frequently asked questions
Why would a team deliberately schedule a job to run more often than needed?
It’s rarely deliberate. When a job is first set up, the team doesn’t always know how often the data needs to refresh, so the safer choice is to run it more often than necessary “just in case.” That decision made sense at the time – the problem is that nobody goes back to revisit it once the real usage pattern is clear.
If each of these jobs is small, why does it matter?
Because they add up. One overly frequent job is barely worth anyone’s time to investigate. A handful of them, scattered across different pipelines and set up by different people over time, is a real and ongoing slice of your data budget – one that’s easy to miss precisely because no single piece of it stands out.
Is this just a cost problem?
No – it also makes your pipeline harder to trust. A table that updates constantly looks important even when it isn’t, which can mislead anyone trying to understand what actually matters in your system. It’s also one more thing that can fail overnight, and one more alert for your team to chase down for no real reason.
Why don't teams catch this themselves?
It would mean knowing, for every table in your pipeline, how often it’s written to versus how often it’s actually used, and then tracing that back to the exact job responsible – across a system nobody holds fully in their head. That’s not a realistic manual audit, so these jobs tend to just keep running.
How does Seemore find these without a manual audit?
Seemore’s Frequency Optimization insight does this automatically. It looks for tables being refreshed far more than they’re used, traces the issue back through your pipeline’s lineage to the exact job responsible, and tells you what it’s costing you – so there’s nothing to go searching for yourself.
What should we do once we find one of these jobs?
Seemore tells you exactly what to change – typically reducing or disabling runs in a specific time window – along with what that’s worth annually, so you can decide if it’s worth acting on before you touch anything.