TL;DR
The Datadog Snowflake integration is an API based connection that pulls query history, warehouse load, credit usage, and security logs from Snowflake into Datadog dashboards and monitors. Set it up with a dedicated low privilege role, a separate small warehouse for collection queries, and alerts tied to real operational thresholds, not every metric Datadog can technically collect.
Key Takeaways The integration reads from Snowflake’s ACCOUNT_USAGE and ORGANIZATION_USAGE schemas through a dedicated service role, not a live agent inside Snowflake. Most ACCOUNT_USAGE views carry roughly two hours of latency, with some ranging from 45 minutes to three hours, so Datadog dashboards are near real time, not instant. A handful of signals, query execution time, warehouse queueing, credit consumption, and failed tasks, cover most of what daily operations actually need. Credit usage data only becomes cost accountability once it is tagged by warehouse, team, and workload, a governance step Datadog does not perform on its own. Native Snowsight and Resource Monitors still win for direct account administration. Datadog wins once Snowflake needs to sit beside application, pipeline, and infrastructure telemetry. Kanerika, a Snowflake Select Tier Partner, has used Snowflake platform work to cut manual data reconciliation by 60% and speed analytics delivery threefold for a North American beverage manufacturer. The 2 A.M. Page That Starts in Snowflake and Ends Somewhere Else An on call engineer gets paged for a latency spike on a customer facing dashboard. The application logs look clean, and the load balancer looks clean too. Yet the trail eventually leads to a Snowflake warehouse that has been queueing queries for twenty minutes.
Nobody on the incident bridge has Snowsight open, because Snowsight was never part of the on call rotation. By the time someone finds the slow query, the customer has already refreshed the page four times.
That gap sits between where a data platform problem starts and where the team that owns incident response actually looks. The Datadog Snowflake integration exists to close it. This guide covers how the integration actually works, which metrics and alerts are worth building around, and how to set it up without over privileging it. It also covers where the integration fits next to Snowflake’s own native monitoring.
What the Datadog Snowflake Integration Actually Does The Datadog Snowflake integration is a native, API based connection that pulls operational telemetry out of a Snowflake account and into Datadog. It does not install an agent inside Snowflake or run continuously in the background the way an infrastructure agent does.
Instead, Datadog authenticates to Snowflake through a dedicated user and role, then queries Snowflake’s own usage schemas on a set interval. The result, as Datadog frames it directly , is dashboards, monitors, and log analysis views. Together, they surface long running queries, warehouse performance, credit consumption, storage growth, task failures, and login activity, all inside the tool most platform and SRE teams already live in.
According to Datadog’s own integration documentation , the connection collects account and organization usage metrics and query history logs. Where a team turns on Data Observability, the integration adds table level freshness and volume signals through Snowflake Trail event tables. That is the same category of coverage compared across dedicated data observability tools .
The Two Directions This Term Can Mean In practice, the keyword itself hides an important fork. “Datadog Snowflake integration” can mean sending Snowflake telemetry into Datadog for monitoring, which is what this guide covers. It can also mean moving Datadog’s own observability data into Snowflake for long term analysis, a separate data pipeline pattern built with a connector or ETL tool.
Direction What It Is For How Teams Typically Build It Snowflake to Datadog Monitor Snowflake performance, cost, and security from inside Datadog The native Snowflake integration tile, covered in this guide Datadog to Snowflake Store or analyze Datadog metrics and logs inside Snowflake for long term reporting A separate ETL or reverse ETL pipeline, not the native integration
This guide focuses on the first direction from here on. That choice matches both Datadog’s native integration and the way most enterprise teams actually search for this topic. Teams still deciding whether Snowflake is the right foundation at all, versus a cloud native warehouse, will find that comparison covered separately in Kanerika’s Snowflake versus AWS guide.
On-Demand Webinar
Snowflake + Fabric: Expert Strategies for Interoperability, Data Sharing & Migration
A recorded Kanerika session on moving data between Snowflake and other platforms without breaking governance, useful context for teams weighing how far to extend Snowflake into the rest of their stack.
Watch the Webinar → Why Snowsight Alone Stops Being Enough Snowsight, Snowflake’s built in interface, is genuinely good at showing what is happening inside Snowflake. Query profiles, warehouse activity, and account usage views are all there natively. For a single, contained Snowflake environment, that can be sufficient on its own.
The friction shows up once Snowflake stops being a standalone system and becomes one dependency among many. Three patterns tend to force the issue.
Query and warehouse problems surface late, because nobody is watching Snowsight the way an on call rotation watches an incident dashboard. Teams typically discover a slow query or an overloaded warehouse when a downstream report is late, not when it starts.
Credit spikes arrive without a clear owner. Snowflake’s own ACCOUNT_USAGE views show what the account spent. However, connecting a spend spike back to a specific team, dashboard, or scheduled job takes deliberate tagging work that Snowsight does not do automatically.
Case Study
28% Cost Savings With a Seamless Snowflake Migration
Kanerika helped an enterprise analytics team modernize onto Snowflake with governed, well-scoped warehouses, cutting platform costs by 28% without slowing reporting down.
Read the Case Study → Snowflake activity also lives apart from the rest of the stack. Application traces, cloud infrastructure metrics, dbt job runs, and API errors all live in whatever data pipeline monitoring platform the rest of engineering already uses. But Snowflake never designed its native tools to sit inside that same view.
In short, bringing Snowflake telemetry into that shared observability layer is the actual value proposition, not replacing Snowsight for day to day account administration.
How the Integration Works Under the Hood The mechanics are simpler than the setup checklist below might suggest. A team creates a dedicated Snowflake role and service user first, scoped to exactly the usage views and schemas the integration needs.
Datadog authenticates to the Snowflake account using that service user, most commonly through key pair authentication rather than a password. Then, on a set collection interval, Datadog runs read only queries against Snowflake’s ACCOUNT_USAGE and ORGANIZATION_USAGE schemas, along with any custom SQL metrics a team has configured. It turns the results into dashboards, monitors, and log entries.
When a team enables Data Observability, Datadog also reads Snowflake Trail event tables for Snowpark applications , extending visibility into custom code running inside Snowflake beyond standard SQL queries. It is a parallel concern to AI agent observability for teams running agentic workloads on top of Snowflake data.
Teams that also run Databricks will recognize the pattern from Databricks system tables , which fill a similar cost and reliability monitoring role on that platform.
One detail catches teams off guard the first time a dashboard looks stale. Snowflake’s own documentation states plainly that most ACCOUNT_USAGE views carry roughly two hours of latency, with a range between 45 minutes and three hours depending on the view. Datadog inherits that latency. As a result, a credit spike from ten minutes ago will not show up instantly, no matter how a team configures the integration.
What Teams Need Before Setup A short prerequisites pass avoids the most common cause of a stalled setup, which is discovering a missing permission halfway through configuration.
On the Snowflake side, teams need administrative access to create a new role and user, plus a Snowflake account identifier or account URL. They also need to decide on an authentication method, most commonly key pair credentials. If Snowpark or Native App telemetry is in scope, teams should confirm event table access in advance.
On the Datadog side, the account needs permission to install integrations and access the Snowflake integration tile. Retaining Snowflake logs beyond the base metrics requires Log Management. Cloud Cost Management adds deeper cross cloud spend reporting. Data Observability, meanwhile, is a separate add on for freshness, volume, and lineage monitoring.
One editorial note matters more than it sounds like it should. Teams should check every specific grant statement and SQL script against Datadog’s current integration documentation immediately before use. An older blog post or internal runbook is not a safe substitute. Snowflake and Datadog both revise required privileges as the integration adds new data sources.
Setting Up the Datadog Snowflake Integration The setup itself follows a predictable sequence once the prerequisites are in place. Each step below maps to a specific, low risk configuration choice rather than a single giant grant.
Step 1: Create a Dedicated Monitoring Role and Warehouse The integration should never run under ACCOUNTADMIN or any broad administrative role. A dedicated role gives clear ownership, makes future audits simple, and limits the blast radius if the service user’s credentials are ever compromised.
Pair that role with a dedicated, small warehouse reserved for Datadog’s own collection queries. Running monitoring queries through a shared, business critical warehouse just adds Datadog’s own query load to the exact contention problem the integration exists to detect.
Step 2: Create the Service User and Choose an Authentication Method The service user should have a default role and default warehouse set explicitly, so a misconfigured session cannot silently fall back to a broader permission set. Key pair authentication is the safer default over a static password, and it should sit on a defined rotation schedule rather than staying static indefinitely.
Where the Snowflake account enforces network policies, teams should restrict the service user’s access to Datadog’s documented IP ranges rather than leaving it open.
Step 3: Grant Only What the Integration Actually Needs Least privilege is not a slogan here, it changes what the role can see if it is ever misused. Standard account usage metrics need one set of grants, while organization level metrics need a broader one. Query history logs, security logs, event tables, and custom SQL metrics each add their own specific access requirement beyond that.
Grant only the tier a team is actually planning to use on day one, then expand deliberately as Log Management, Cloud Cost Management, or Data Observability get turned on.
Step 4: Connect the Account in Datadog and Validate Collection Inside Datadog, the Snowflake integration tile takes the account URL, the service user’s authentication details, and the correct site or region setting. Once saved, the validation pass matters as much as the setup itself.
Confirm the Snowflake overview dashboard is populating, that warehouse metrics carry the expected tags, and that query history logs are arriving. Finally, no permission errors should be showing in the integration’s own status panel before the rollout counts as complete.
The Snowflake Metrics Worth Watching in Datadog Datadog can technically surface dozens of Snowflake signals, and Datadog’s own metrics guide documents most of them. In reality, most teams do not need to watch all of them daily. A smaller set covers most real operational decisions.
Table 1: Core Snowflake Signals for Daily Operations
Monitoring Area Signals to Watch What They Usually Indicate Query performance Execution time, bytes scanned, failed queries Inefficient SQL or a warehouse sized wrong for the workload Warehouse load Average running, average queued load, blocked queries Concurrency or capacity pressure on a shared warehouse Credit usage Credits used, cloud services credits, credits by warehouse Cost spikes, oversized warehouses, or runaway scheduled jobs Tasks and pipelines Failed tasks, task execution duration Broken or delayed data pipelines feeding downstream reports Storage Database storage, stage storage growth Unexpected retention or duplication driving storage cost up Security Login failures, unusual query or role activity Credential issues or access outside normal patterns
Query performance signals such as execution time and bytes scanned expose slow or expensive SQL before it becomes a support ticket. Similarly, warehouse load metrics like queueing and blocked queries usually point to a concurrency problem before users notice anything beyond “the dashboard is slow today.”
Credit consumption metrics are the ones most often watched too loosely, checked monthly instead of tracked against a baseline. That gap is exactly what turns a small warehouse sizing mistake into a quarter of unexplained spend. For example, teams running a mixed platform estate face the same calculus covered in Kanerika’s guide to Databricks SQL warehouse sizing and cost optimization .
Kanerika Service
Data Engineering for Snowflake Monitoring and Cost Governance
Kanerika’s data engineering teams design the warehouse ownership model, tagging standards, and alerting layer that make a Snowflake monitoring rollout actually stick.
Explore Data Engineering Services Datadog Alerts That Prevent Incidents Instead of Adding Noise An alert that fires on every metric Datadog can collect trains a team to ignore Datadog. The alerts worth building are the ones tied to a specific operational threshold and a specific owner.
Query and Warehouse Alerts A long running query alert should trigger when execution time crosses an agreed baseline for a sustained window. Tag it by warehouse, database, and role so the alert pages the right team. A separate alert on failed query rate, rather than every isolated failure, catches genuine regressions without paging someone for one flaky retry.
A warehouse queue alert using queued load or blocked query signals catches capacity pressure early enough to act on it. That could mean resizing a warehouse or splitting a workload across two. Where Snowflake’s storage footprint is also growing faster than expected, transient tables are worth reviewing. They can trade Time Travel retention for lower storage cost on data that does not need it.
Cost and Pipeline Alerts A credit usage anomaly alert compares current consumption against a historical baseline or a team’s daily budget. A single fixed number, by contrast, stops being meaningful as usage grows. Failed task alerts should route directly to the team that owns the pipeline, not to a shared inbox nobody checks until the next stand up. That routing discipline starts with how a team selects its data orchestration tools in the first place.
A data freshness alert watches for a table that misses its expected update window. It catches a silent pipeline failure long before a downstream analyst notices the numbers look wrong.
Every alert built this way should carry an explicit owner, a severity level, and a runbook link. An alert with no owner is a notification, not an incident response tool.
Datadog Versus Native Snowflake Monitoring Datadog does not replace Snowsight, and treating the integration as a full substitute for native tooling misses where each one actually wins.
Table 2: Where Each Tool Wins
Capability Native Snowflake Tools Datadog After Integration Direct account administration Strong, purpose built Limited, read only visibility Query and warehouse inspection Strong Strong, once configured Cross system correlation Limited to Snowflake itself Strong, sits beside application and infrastructure data Centralized alert routing Available, but a separate configuration Strong, one alerting and on call system Cost attribution across cloud systems Snowflake focused Broader, spans cloud and application spend
The practical guidance follows directly from that table. Use Snowflake’s own tools for direct account administration and hands on query tuning.
Use Datadog for the moment a Snowflake signal needs to sit next to an application error, an infrastructure metric, or a pipeline failure from somewhere else in the stack. In the same way, teams running a Microsoft heavy estate alongside Snowflake face the same decision when weighing Datadog against native Azure monitoring tools .
Turning Credit Data Into Real Cost Accountability Installing the integration answers “what is Snowflake spending.” It does not answer “which team, workload, or dashboard is responsible for that spend.” That second question is where most Snowflake cost conversations actually stall.
Credits used by warehouse only becomes a governance signal once a team organizes warehouses around ownership in the first place. That means one warehouse per team or workload, rather than one shared warehouse everyone queries against. Without that separation, a credit spike shows a number with no name attached to it.
Tagging closes that gap. Environment, team, cost center, and application tags applied consistently at the warehouse and query level let a credit anomaly alert point at an actual owner. Otherwise, it defaults to a shared support queue. That tagging discipline is exactly the kind of platform engineering work that determines whether a monitoring rollout produces real cost control or just a prettier dashboard.
A budget alert without an assigned owner rarely changes behavior, because nobody feels responsible for acting on it. The teams that get real value out of Snowflake credit monitoring treat tagging and ownership as part of the rollout. They do not treat it as an afterthought to revisit once costs are already a problem. It is the same discipline behind effective data pipeline optimization .
Security and Governance Guardrails The integration touches Snowflake’s query history, which can include SQL text referencing table and column names, and in some cases values embedded directly in a query. That overlaps directly with sensitive data discovery work. Ultimately, deciding what to collect and retain is a governance call, made jointly with security, ahead of a purely technical one.
ACCOUNTADMIN should never be the integration’s day to day role, for the same reason no service account should run under an administrative identity long term. A dedicated, least privilege role with key pair authentication on a rotation schedule reflects the same data access governance principles. Those principles keep the blast radius small if credentials are ever exposed.
Security and data teams should agree in advance on what to collect and whether query text needs masking before ingestion with a purpose built data masking tool . They should also settle who can access the resulting logs inside Datadog and how long the team retains that data. Production and non production Snowflake accounts should also run through separate integration configurations. That way, a test environment’s noisy activity never dilutes production alerting, a pattern also covered under broader data security posture management .
These are the same governance questions Kanerika’s teams work through on every Snowflake data governance engagement, independent of which observability tool sits downstream.
Watch on YouTube
AI Agents & Data Security: Snowflake’s New Approach
A Kanerika walkthrough of how Snowflake is evolving its security model for AI agents and data access, the same least-privilege thinking that should govern a Datadog service role.
When the Integration Is Worth Building The integration earns its setup cost when Datadog is already the team’s primary monitoring platform. It is also worth building when several teams share Snowflake warehouses without a clear ownership model. The same logic applies when incident response regularly needs to connect an application failure back to Snowflake activity.
It is also the right call once Snowpark, Native Apps, or a growing set of scheduled tasks need shared monitoring. That monitoring should sit alongside everything else running through the same on call rotation. That is the same territory covered by broader AIOps tooling evaluations.
It is a poor fit for a small, contained Snowflake environment where Snowsight already answers every question that comes up. It is also a poor fit for a team with no dedicated owner for dashboards and alert response. Adding a second monitoring surface without anyone assigned to watch it just adds maintenance, not visibility.
Common Setup Problems and How to Diagnose Them Table 3: Troubleshooting the Integration
Symptom Likely Cause What to Check First No metrics appear Account URL, authentication, or role misconfiguration Connection settings and the service user’s login history Organization level metrics missing Organization usage access was never granted Required organization usage privileges on the role Query logs do not show up Log collection permissions are incomplete Integration log settings and query history grants Data looks delayed Normal ACCOUNT_USAGE view latency Snowflake’s documented latency window for that view Authentication suddenly fails Key pair expired or was rotated incorrectly Public key assignment on the service user
Most failures trace back to one of two root causes. Either a role is missing a specific grant, or a piece of documentation changed since the team first configured the integration. Re checking the current official setup page resolves more issues than any generic troubleshooting checklist.
Checklist
Snowflake Performance Optimization Checklist
A practical checklist for keeping Snowflake warehouses, queries, and costs healthy, a useful companion once monitoring surfaces the first problem.
Get the Checklist → Datadog Snowflake Monitoring: How Kanerika Builds the Layer Around It Installing the Snowflake integration tile in Datadog takes minutes. Deciding which data actually matters, how warehouse costs map back to the teams generating them, and which alerts deserve a real response is the harder, ongoing work. It is the part most teams underestimate at rollout.
Kanerika is a Snowflake Select Tier Partner . Its data engineering teams design the monitoring, cost governance, and security architecture around Snowflake environments. That work sits inside standard data integration and data analytics delivery, independent of which observability tool a client already runs.
That experience shows up directly in client outcomes. The client is a North American beverage manufacturer running bottling and distribution operations across multiple shareholder owned facilities. A fragmented mix of legacy and hybrid systems, spanning ERP, HR, and IoT sources, was slowing decisions and making it hard to scale.
Kanerika’s Snowflake migration consolidated that environment onto a governed, unified platform. The result was 60% less manual data reconciliation, 40% faster data reporting cycles, three times faster analytics delivery, and $130K in annual savings from retired legacy licensing and maintenance costs.
Dedicated roles instead of shared administrative access, warehouses scoped to actual ownership, and tagging built in from day one all matter here. Combined, they turn a Datadog Snowflake integration into an operating model rather than a dashboard. Teams evaluating their own Snowflake monitoring and cost governance setup can start a working session with Kanerika . That session maps current warehouse usage, access patterns, and alerting gaps against what the environment actually needs.
Talk to Kanerika
Talk to Kanerika About Snowflake Monitoring and Cost Governance
Get a working session on your own Snowflake environment: warehouse ownership, tagging, alert design, and where Datadog fits next to Snowsight.
Schedule a Demo → Wrapping Up The Datadog Snowflake integration is straightforward to install and easy to under use. The real work is in the decisions around it. Which metrics matter enough to alert on, how the team ties credits back to an owner, and how tightly it scopes the service role all shape the outcome.
Teams that treat setup as a one time task tend to end up with a dashboard nobody checks. Teams that treat it as the start of an ongoing monitoring and cost governance practice get a genuinely useful early warning system. It catches a Snowflake problem before it becomes a customer facing incident, not after.
Frequently Asked Questions
What is the Datadog Snowflake integration? The Datadog Snowflake integration is an API based connection that collects operational data from a Snowflake account and sends it to Datadog for dashboards, log analysis, monitors, and cost reporting. It can pull account usage metrics, organization usage metrics, query history, security logs, event table data, and custom SQL metrics, depending on which grants and Datadog products are enabled.
How does Datadog connect to Snowflake? Datadog connects through a dedicated Snowflake user and role scoped to the required usage schemas and views, most commonly authenticated with a key pair rather than a password. Once that account and its credentials are entered into the Snowflake integration tile in Datadog, the connection runs on a set collection interval without needing a live agent inside Snowflake.
What Snowflake metrics can Datadog monitor? Datadog can monitor query execution time, bytes scanned, warehouse load and queueing, credit consumption, storage growth, task failures, and login activity, among other signals from Snowflake’s account and organization usage schemas. The exact set available depends on which grants the service role has and whether Log Management, Cloud Cost Management, or Data Observability are enabled.
Can Datadog monitor Snowflake query performance? Yes. Query history logs and metrics let teams find slow, failed, or blocked queries and filter them by warehouse, user, database, and role. This is one of the more common reasons teams add the integration, since it surfaces query problems earlier than waiting for a downstream report to run late.
Can Datadog monitor Snowflake costs? Yes, at the level of credit consumption by warehouse and by organization, sourced from Snowflake’s own usage views. Turning that raw credit data into real cost accountability by team or workload depends on tagging and warehouse ownership design that sits outside the integration itself, not on Datadog alone.
Does the Datadog Snowflake integration need an agent installed? No. Datadog describes the standard Snowflake integration as API based, meaning it authenticates directly to the Snowflake account and queries usage schemas on an interval, rather than running a persistent agent process inside the Snowflake environment the way a host based integration would.
Why do Snowflake metrics in Datadog sometimes look delayed? Snowflake’s own ACCOUNT_USAGE views carry built in latency, roughly two hours for most views and a range between 45 minutes and three hours for others, based on Snowflake’s official documentation. Datadog inherits that latency because it reads from the same views, so a dashboard reflecting activity from the last few minutes is expected behavior, not a broken integration.
Is the Datadog Snowflake integration secure to run in production? It can be, when configured with a dedicated service user, a least privilege role instead of ACCOUNTADMIN, key pair authentication on a rotation schedule, and clear rules for how query logs are retained and who can access them inside Datadog. Running the integration under a broad administrative role, or skipping the conversation about what query text gets collected, is where the real security risk sits.
