Observability for Snowflake App Runtime

This topic describes how to inspect the state of a running Application Service and how to read its container logs. In Cortex Code CLI or Cortex Code Desktop, you can ask the agent to check status, show logs, or diagnose deployment issues. For example: Show me the logs for my warehouse-monitor app.

Check service status

Use SHOW APPLICATION SERVICES to list services you can see, along with their current state, deployed package, and version:

SHOW APPLICATION SERVICES;

Use DESCRIBE APPLICATION SERVICE to inspect a single service in more detail:

DESCRIBE APPLICATION SERVICE my_db.my_schema.my_app;

A service can be in one of the following states:

  • PENDING: the service is starting up.
  • RUNNING: the service is running and can accept requests.
  • SUSPENDING: a suspend is in progress.
  • SUSPENDED: the service is stopped and not consuming compute.
  • FAILED: a container in the service encountered an unrecoverable error.
  • FAILING: the service is transitioning to a failed state.
  • DONE: the service ran to completion (job-style runs only).
  • CANCELLED: a job-style run was cancelled.
  • CANCELLING: a cancel is in progress.
  • DELETING: a drop is in progress.
  • DELETED: the service has been dropped.
  • INTERNAL_ERROR: the service is in an unexpected internal state.

Read container logs and telemetry

The fastest way to read container logs is with the Snowflake CLI:

snow app events
snow app events --last 1000

By default, the command returns the 500 most recent log lines for the Application Service defined in your snowflake.yml (--type log). Output is capped at 100 KB.

Use --type to select another observability stream:

# Historical logs from the event table (works after suspend; short ingestion lag)
snow app events --type log --since 6h

# CPU / memory / network metrics from the event table
snow app events --type metric --metric cpu --since 1h

# Service and container lifecycle events
snow app events --type lifecycle --since 2d

--since and --until accept relative shorthand such as 30m, 6h, or 2d, or an absolute UTC timestamp. Metric and lifecycle streams are historical and default to the last hour when you don’t pass a time window. With --type metric, use --metric cpu, memory, or network, and --raw for unconverted values.

You can also read live container logs with SQL using SYSTEM$GET_APPLICATION_SERVICE_LOGS. The second argument limits the number of lines returned (default: 500). For a multi-instance service, pass a third argument to choose the instance by its number, starting from 0:

SELECT SYSTEM$GET_APPLICATION_SERVICE_LOGS('my_db.my_schema.my_app');
SELECT SYSTEM$GET_APPLICATION_SERVICE_LOGS('my_db.my_schema.my_app', 1000);
SELECT SYSTEM$GET_APPLICATION_SERVICE_LOGS('my_db.my_schema.my_app', 500, 1);

The role that reads logs needs the MONITOR privilege on the service.

Quick troubleshooting runbook

Use this sequence when a deploy or running app looks unhealthy:

  1. Check service health:

    DESCRIBE APPLICATION SERVICE my_db.my_schema.my_app;

  2. Confirm the service appears in inventory:

    SHOW APPLICATION SERVICES IN SCHEMA my_db.my_schema;

  3. Pull recent logs quickly:

    snow app events --last 500

  4. Pull logs with SQL for scripts and worksheets:

    SELECT SYSTEM$GET_APPLICATION_SERVICE_LOGS('my_db.my_schema.my_app', 500);

  5. If ALTER APPLICATION SERVICE ... RESUME fails with a blocked runtime image error, upgrade to a new package version before resuming. See Usage notes.

If the service endpoint is not available, run snow app open --print-only to check whether the URL is resolvable from the current deployment state.

Use an event table for structured logs

For persistent, queryable logs, configure an active event table on your account and emit structured logs from your application code. The event table receives logs, metrics, and traces emitted by your containers and by Snowflake. For more information, see Logging, tracing, and metrics.

See also