Snowflake SQL compilation error object USAGE_EVENTS does not exist: churn scoring job aborted

TL;DR

The table is probably there, your session is just not looking where it lives, or your role cannot see it. Snowflake resolves an unqualified name against the sessions current database and schema, and scheduled jobs often run with a different context and role than the analyst who wrote the query. Fully qualify the name, set the job context explicitly, confirm the role grants, and the scoring job compiles without anyone recreating a table that already exists.

Snowflake SQL compilation error object USAGE_EVENTS does not exist: churn scoring job aborted

Use this when

• The scoring job fails with SQL compilation error object does not exist
• The same query works when run interactively by an analyst
• The table was recently moved, renamed, or rebuilt by a pipeline such as dbt

Not for this skill when

• The table was genuinely dropped and no successor exists, which the catalog check in step two will prove
• The query runs in Snowflake but fails in a downstream tool with a different error

Steps

1. Copy the failing statement from the job log exactly as executed, including any generated SQL your scoring tool produced, and note the role, warehouse, database, and schema the job session used. Interactive success means little until you reproduce the jobs exact session context, because name resolution is context dependent. Verify: the job session context is documented from the log or the task definition
2. Search the catalog for the table. Query the information schema across likely databases for a table named like USAGE_EVENTS, and check for case differences, because a table created with quoted mixed case name must be referenced with that exact case and quoting forever after. Also check whether a recent dbt or pipeline run rebuilt it under a new schema such as a production schema with an environment prefix. Verify: the tables real location, exact name case, and owning schema are found or its genuine absence is proven
3. Test access as the job role. Switch to the jobs role in a worksheet and run a simple select count against the fully qualified name. If the object still reports as not existing under that role, it is a grants problem in disguise, because Snowflake hides ungranted objects behind the same message. Have the owner grant select on the table and usage on its database and schema to the job role. Verify: the job role can select from the fully qualified table in the test
4. Fix the job properly. Use the fully qualified three part name in the query, and set database, schema, and role explicitly in the task, connection, or session parameters instead of inheriting defaults. Rebuilds and environment promotions then cannot silently repoint the job at an empty schema with a similar name. Verify: the corrected job compiles and runs under its scheduled identity, not only interactively
5. Run the missed scoring window and reconcile. Compare the row count the job read against the source pipelines own published count for the same window, and re-score every account whose health depended on the failed runs so the at-risk list reflects reality, not the outage gap. Verify: reconciled counts match and the missed scoring runs are completed
6. Prevent recurrence with a lightweight pre-flight check in the job that verifies the expected tables exist and are selectable as the job role, failing loudly to the data channel before scoring starts, plus a note in the pipeline runbook recording the tables owning team and rebuild process for the next rename. Verify: the pre-flight check exists and a test with a wrong schema name fails loudly

Why it happens

Snowflake resolves unqualified identifiers using the session context and filters visibility by role grants, returning a single does not exist message for several distinct causes, wrong schema, wrong database, wrong case, missing grant, or a real drop. Scheduled jobs inherit context from their connection or task definition, which drifts from interactive defaults over time, so a query can be correct for a person and unresolvable for the job.

Compatibility: Snowflake tasks, sessions, roles and grants, information schema, and upstream pipelines such as dbt, in current Snowflake versions.

Variants and edge cases

Snowflake object does not exist but table exists

['The classic phrasing for context or grants. Snowflake deliberately gives the same error for missing and for ungranted, so always test as the failing role.']

SQL compilation error 002003 object not found Snowflake

['The error-code phrasing. Object identifier errors at compile time are resolution problems, not data problems, so no data backfill will help until resolution is fixed.']

dbt model renamed scoring job broke Snowflake

['The rename variant. When a pipeline promotes models between schemas, downstream jobs with short names break first, which is a sign to qualify names and pin contexts everywhere.']

Edge cases to work through before you close the incident:

• Views layered on the table fail the same way if the underlying grant chain breaks. Grant on the full chain the job touches, not only the final object.
• A table recreated by a full refresh pipeline can lose manually applied grants. Prefer grants managed in code alongside the pipeline definition.
• If two databases hold a table with this name, qualification protects you, but also confirm you qualified to the production one and not a stale development copy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VNOQw6KBEN11XFRBUPvM7g