The Observability Tax
Every Snowflake customer pays an observability tax. Every single one.
Checking your task graph in Snowsight? Credits. Querying QUERY_HISTORY to troubleshoot performance? Credits. That dashboard your FinOps team refreshes every morning? Credits. Running the Trust Center scanner? Credits. Even browsing your database list uses cloud services — and yes, that can show up on your bill.
As with all forms of tax — we want to be as efficient as possible.
Yes, Monitorial is a paid platform. Your total observability cost should still be lower.
Our architecture is designed so that the efficiency gains outweigh the subscription — meaning your total cost of observability (Monitorial + Snowflake compute) is less than the DIY alternative. And you get:
- 200+ pre-built, maintained monitors
- Carefully architected by our engineering team using the best of Snowflake
- Intelligent routing and deduplication
- Auto-resolve lifecycle (PagerDuty, Slack, Teams)
- AI workload velocity detection
- No SQL to write, tune, or maintain
- And many more…
Two Dimensions of Observability Tax
More observability means more observability tax. Whether that scales linearly depends on how you've built it.
Raw Observability Tax
The credits consumed by any observability activity.
- Every query that asks “is everything OK?” costs credits
- More monitors = more queries = more credits
- Full table scans on metadata views add up fast
- This doesn't go away — regardless of build vs buy
Human Observability Tax
The people cost of building and maintaining observability.
- Someone writes the monitors
- Someone tunes the thresholds
- Someone maintains them when the platform changes
- Someone triages the noise
You can outsource some of the human tax with a product — build vs buy. But regardless of which path you choose, you still pay the raw tax. Every query costs credits. That doesn't go away. But with Monitorial Pulse, you're maximising the value for every observability tax dollar you spend.
The Efficiency Spectrum
High observability doesn't have to mean high tax. Implementation matters.
| Approach | Observability | Raw Tax | Human Tax |
|---|---|---|---|
| Browse Snowsight a few times a day | Low | Low | Low |
| DIY monitors (hand-written SQL, scheduled tasks) | Medium | High | Very high |
| Full engineering coverage (bespoke platform) | High | Variable | High |
| Monitorial | High | Optimal | Low |
Reducing Raw Tax
DIY monitoring is expensive — each monitor scanning metadata views independently, full table scans, no optimisation. Every additional check multiplies the cost linearly.
Carefully architected by our engineering team using the best of Snowflake’s platform capabilities. 200+ monitors share optimised access patterns on serverless tasks — dramatically less compute than the equivalent DIY approach.
Your observability tax should be a predictable line item under “the cost of doing business” — not a surprise on your monthly bill.
DIY Monitoring
Each monitor = independent full scan
Monitorial
Optimised shared access patterns
Same coverage. Fraction of the compute.
Reducing Human Tax
The platform changes. Your monitors shouldn't need to.
No SQL to Write
200+ pre-built monitors. Parameterised, documented, ready to activate.
No Triage Burden
Rules engine handles routing, suppression, and deduplication automatically.
No Manual Close
Trigger/resolve lifecycle — PagerDuty auto-resolves on recovery.
No Maintenance
Monitor catalogue is maintained and updated. New Snowflake features = new monitors shipped to you.
The AI Dimension
Static pipelines are predictable — same rows, same cost, every day. Set a threshold, you're done.
AI workloads are non-deterministic. An agent reasons, decides it needs more context, queries again, evaluates, loops. The cost is a function of how much the model thinks — not how much data you have.
The old monitoring model — check a metric, compare to threshold — doesn't fit here. You need rate-of-change detection: “this thing is spending faster than expected” rather than “this thing exceeded a fixed number.”
Native Controls vs Real-Time Detection
| Control | Strength | Gap |
|---|---|---|
| Resource budgets | Monthly credit governance | Periodic enforcement (not real-time) |
| Statement timeouts | Per-query execution limits | Doesn't detect multi-query accumulation |
| Model allowlists | Restrict expensive LLMs | Doesn't detect reasoning loops |
| Guardrails | Prompt injection protection | Security scope, not cost scope |
These are the right monthly and per-query guardrails. Monitorial adds the real-time detection layer.
Fire Insurance vs Smoke Detector
Native budgets are fire insurance — they cap your total damage eventually. Monitorial is the smoke detector — it catches the problem while it's small.
Fire Insurance
Native Budgets
Monthly credit caps with periodic enforcement. Limits damage eventually. Essential for governance.
Smoke Detector
Monitorial
Per-minute velocity detection with immediate alerting. Catches problems before they accumulate. Keeps your tax efficient.
You need both. But the smoke detector is what saves you money day-to-day.
Make Your Observability Tax Efficient
Install from Snowflake Marketplace and start with a full Enterprise trial — every feature unlocked from day one. Keep what works, scale down if you need to.