Metabase dashboard card failed with error "column does not exist" how to fix
Fixes a Metabase card that fails because a column no longer exists by syncing the schema and updating the question to the current field name. Use when a saved question breaks after a table change. Not for a whole database connection failure affecting every card.
TL;DR
Sync the database schema in Metabase first, then open the failing question and replace the removed or renamed field everywhere it appears, including filters, groupings and sorts. Save the question, clear the card cache, and reload the dashboard so every copy of the card uses the fixed question. Renaming upstream without updating saved questions is the usual trigger.
column does not existUse this when
- One card fails with a column error while other cards on the same database still work.
- A warehouse migration renamed or dropped a column used by saved questions.
- The notebook editor shows a field highlighted as unavailable in the failing question.
Not for this skill when
- Every card on the database fails at once. Check the database connection before editing questions.
- The card loads but shows wrong values with no error. That is a definition problem, not a missing column.
Steps
- Open the failing question directly, not from the dashboard, and run it to see the full database error naming the column. Verify: the error names a single column that no longer exists in the table
- In Admin settings for the database, run a manual schema sync and then inspect the table field list in the data model. Verify: the new or renamed column appears and the old name is gone
- Edit the question and replace the old field in the data step, filters, summaries, breakouts and sorts with the current field. Verify: the question runs and returns rows in the editor
- If the question is native SQL, update the column name in the query text and check any field filter mappings that point at the old field. Verify: the query runs with the dashboard filters applied
- Save the question, clear cached results for the card from the admin caching page, and reload the dashboard as a viewer. Verify: the card renders current data with no error banner
- Search saved questions and models for other uses of the old column name and fix them before they are opened. Verify: a search for the old name in question definitions returns no active items
Why it happens
Metabase separates the synced field catalog from the queries stored in saved questions. Schema changes propagate to the catalog on sync, but stored questions keep the identifiers they were saved with, so the database rejects them at run time. Models add a second copy of the field reference, which is why fixing the dashboard card alone sometimes leaves the underlying model broken. Updating every stored reference is the durable fix.
Metabase saved questions store field references against the synced field list. When a column is dropped or renamed in the warehouse, the generated query still asks for the old name and the database returns a column error that Metabase shows on the card. A schema sync alone does not rewrite saved questions, it only makes the new field available to pick. Cards built on a model or a cached result can keep failing until the question itself is corrected.
Field notes for Metabase specifically. The admin troubleshooting area, the task history, and the application database query tools give the evidence for most incidents, and the audit views on paid plans show who changed a question or a dashboard and when. Metabase behaviour differs meaningfully between the open source and paid builds, and between the application database choices underneath, so note the exact version when filing or searching for an issue. A question that works in the editor but fails on a dashboard is almost always a dashboard layer setting, which is why the two surfaces should always be tested separately.
For Metabase teams, models are the control point worth investing in. Questions built directly on raw tables inherit every schema change at full force, while models give the team one place to absorb a rename or a type change before it reaches fifty saved questions. Keeping production dashboards on models, and raw table questions in a clearly marked sandbox collection, measurably reduces breakage after warehouse changes. It also gives the schema sync somewhere forgiving to land, since the model owner sees the change before viewers do.
Variants and edge cases
Metabase column does not exist after rename
The rename-triggered phrasing for saved questions.
Metabase saved question broken column sync schema
The sync-focused variant for recently migrated tables.
Metabase dashboard card error missing field fix
The dashboard-level phrasing viewers report.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_N0IrCFZARe0SfX1GCXGafA