13.4 Warehouse Monitoring, Alerts, Event Tables & Performance Explorer

Monitoring Sources: Which One Answers Which Question?

Account Usage vs. Information Schema (exam favorite): SNOWFLAKE.ACCOUNT_USAGE views include dropped objects, keep one year of history, and have latency of 45 minutes to 3 hours depending on the view. INFORMATION_SCHEMA views and table functions have no latency but shorter retention (7 days to 6 months depending on the function) and are scoped to one database.

-- Is BI_WH saturated (queued load) or cold (queued provisioning)?
SELECT start_time, avg_running, avg_queued_load, avg_queued_provisioning, avg_blocked
FROM TABLE(INFORMATION_SCHEMA.WAREHOUSE_LOAD_HISTORY(
  DATE_RANGE_START => DATEADD('hour', -8, CURRENT_TIMESTAMP()),
  WAREHOUSE_NAME => 'BI_WH'))
ORDER BY start_time;

Interpretation:

• Sustained AVG_QUEUED_LOAD > 0 → concurrency pressure: scale out (multi-cluster) or split workloads.
• AVG_QUEUED_PROVISIONING > 0 around resumes → auto-suspend may be too aggressive for the workload's gaps.
• AVG_RUNNING far below capacity for long periods → the warehouse may be oversized or its auto-suspend too long.

Alerts and Notifications

An alert is a schema-level object that runs a condition (a SQL statement, usually EXISTS (...)) and, if it returns rows, runs an action:

CREATE OR REPLACE ALERT ops.monitoring.long_queue_alert
  SCHEDULE = '5 minute'                         -- omit WAREHOUSE for a serverless alert
  IF (EXISTS (
        SELECT 1
        FROM TABLE(INFORMATION_SCHEMA.WAREHOUSE_LOAD_HISTORY(
               DATE_RANGE_START => DATEADD('minute', -10, CURRENT_TIMESTAMP()),
               WAREHOUSE_NAME => 'BI_WH'))
        WHERE avg_queued_load > 1))
  THEN
    CALL SYSTEM$SEND_EMAIL('ops_email_int', 'dba-team@example.com',
                           'BI_WH is queuing', 'Queued load > 1 in the last 10 minutes');

ALTER ALERT ops.monitoring.long_queue_alert RESUME;   -- alerts are created suspended

Key facts:

• Types: an alert on a schedule (every n minutes or a cron expression) evaluates existing data; an alert on new data evaluates only new rows in a table or view — for example, new ERROR rows in the event table.
• Compute: serverless alerts (no WAREHOUSE, requires EXECUTE MANAGED ALERT; scales up to the equivalent of XXLARGE) or a specified warehouse (requires USAGE on it).
• Privileges: EXECUTE ALERT on the account (grantable only by ACCOUNTADMIN) plus CREATE ALERT on the schema.
• Operations: ALERT_HISTORY shows runs; SUSPEND_ALERT_AFTER_NUM_FAILURES auto-suspends failing alerts.

Notification integrations define where messages go: TYPE = EMAIL (for SYSTEM$SEND_EMAIL), TYPE = QUEUE for outbound messages to Amazon SNS, Azure Event Grid, or Google Cloud Pub/Sub, and TYPE = WEBHOOK for Slack, Microsoft Teams, or PagerDuty. The same integrations serve task error notifications, budgets, and alerts.

Event Tables: Logging, Tracing, and Metrics

An event table is a special table with a predefined schema that stores telemetry emitted by Snowflake objects:

• Logs from stored procedures and UDF handlers (Python, Java, Scala, JavaScript, Snowflake Scripting).
• Traces (spans and events) that show the flow and timing of code.
• Metrics, plus events from Snowpark Container Services, Native Apps, tasks, and dynamic table refreshes.

Setup and control:

• Snowflake provides a default event table, SNOWFLAKE.TELEMETRY.EVENTS, which is active unless you set another; a predefined view, SNOWFLAKE.TELEMETRY.EVENTS_VIEW, can be secured with a row access policy for broader access.
• You can create your own with CREATE EVENT TABLE and activate it with ALTER ACCOUNT SET EVENT_TABLE = db.schema.events;. Associating an event table with a specific database is an Enterprise Edition feature.
• Telemetry levels decide what is captured: LOG_LEVEL (for example ERROR, WARN, INFO), TRACE_LEVEL, and METRIC_LEVEL, settable at account, database, schema, or object level.
• Collecting telemetry has a cost, so capture detail where you need it (for example INFO in development, ERROR in production).

ALTER PROCEDURE etl.procs.load_orders(VARCHAR) SET LOG_LEVEL = 'WARN';

SELECT timestamp, record['severity_text']::STRING AS severity, value::STRING AS message
FROM snowflake.telemetry.events_view
WHERE resource_attributes['snow.executable.name']::STRING ILIKE 'LOAD_ORDERS%'
  AND record_type = 'LOG'
ORDER BY timestamp DESC;

Combine event tables with an alert on new data to page the on-call engineer whenever a pipeline logs an ERROR, instead of waiting for users to notice missing data.

Performance Explorer

Performance Explorer (Snowsight » Monitoring » Performance Explorer) provides interactive charts of SQL workload health:

• Overall activity — are queries succeeding, and can users get work done?
• Change over time — what changed (query volume, warehouse settings, table changes) and when?
• Hot spots — which warehouses, users, or tables deserve attention first?

It surfaces warehouse events and top tables with change events, filtered by the viewer's privileges (some sections need full access or the GOVERNANCE_VIEWER database role). Architects use it to connect a performance regression to a cause — for example, a warehouse resized down on Tuesday or a large table that started receiving heavy updates — before drilling into Query Profile.

Putting It Together: A Monitoring Runbook

1. Budgets and resource monitors catch spend anomalies (13.3).
2. Alerts watch warehouse load, failed tasks, stale streams, or data-quality conditions and notify through notification integrations.
3. Event tables hold the detailed logs and traces needed to debug procedures, apps, and services.
4. Performance Explorer and Query Profile explain why performance changed and guide fixes such as clustering, search optimization, QAS, or warehouse changes.