Monitor a deployed model

Use Snowflake SQL to inspect a deployed model’s objects and refresh status, and understand how refresh schedules affect output consistency.

Prerequisites: You have deployed a model you want to monitor. See Deploy a model.

Monitor a deployment from SQL

Once a deployment succeeds in the CLI, PyRel creates the public schema and the internal schema if they don’t exist yet. You set them with deployment.public_schema and deployment.identity.internal_schema. PyRel then starts any refresh schedule whose run_on_deploy setting is true. Inspect the target schema to verify this.

Check the target schema
```
SHOW SCHEMAS LIKE '<YOUR_TARGET_SCHEMA>' IN DATABASE <YOUR_DATABASE>;
```
Replace <YOUR_TARGET_SCHEMA> and <YOUR_DATABASE> with the target schema you set for deployment.public_schema.
List installed objects

Each output is a view in the public schema, and the data behind it is stored in the internal schema. During deployment, the PyRel compiler decides how to store it: a table, a dynamic table, or nothing stored at all. You can also set this yourself with deployment.materialized and deployment.incremental, globally or on a per-output basis. See Choose how outputs are materialized.
```
SHOW OBJECTS IN SCHEMA <YOUR_DATABASE>.<YOUR_TARGET_SCHEMA>;
```
You should see objects corresponding to each of the concepts and relationships in your model. Each concept object has a column for each property, and each relationship object has a column for each field.

Check the model’s refresh status

The internal schema exposes a REFRESH_STATUS procedure that returns one row per refresh schedule, showing each schedule’s current status. REFRESH_STATUS is the first place to check when a model is not refreshing as expected.

CALL <YOUR_INTERNAL_SCHEMA>.REFRESH_STATUS();

You should see a row for each schedule. The status column can return:

Status	Meaning
`DEPLOY_RUNNING`	A deployment is currently updating the model.
`DEPLOY_FAILED`	The latest deployment failed.
`NEVER_RUN`	The schedule exists but has not run yet.
`RUNNING`	A refresh is currently running.
`SUCCEEDED`	The latest completed refresh succeeded.
`FAILED`	The latest completed refresh failed. The `error` column contains the failure message.

If you configured a prefix or a suffix, the refresh status procedure will carry this prefix or suffix. For example, with a PRJ123_ prefix, the procedure will be called PRJ123_REFRESH_STATUS().

If any of these steps fails or Snowflake does not show the expected objects, continue to Troubleshoot a deployed model.

Understand output consistency

The outputs of a deployed model are eventually consistent with their source data. After a source table changes, deployed outputs will continue to show earlier results until a refresh reads the change and finishes successfully.

Within a refresh run for one schedule, PyRel updates outputs progressively in dependency order: dependencies first, then the outputs that depend on them. Outputs that do not depend on each other may refresh in parallel.

Refresh runs are not snapshot-isolated across all reads. If a refresh reads the same source table more than once, and the table changes between those reads, the refresh may read different versions of that table.

Different refresh schedules run independently. Dependency order is enforced within a schedule, but not between schedules. If dependent outputs are assigned to different schedules, queries may see a mix of older and newer output data while those schedules are refreshing.

For example, consider this model, with one source table S and three model outputs A, B, and C:

If A, B, and C are assigned to the same schedule, a refresh submits updates for A and B first. After both finish, the refresh updates C.

If A, B, and C are assigned to different schedules, there is no cross-schedule ordering guarantee. For example, a query may see A after it has refreshed, B before it has refreshed, and C before it reflects both updates.