--- title: "When a Rig data app run fails" description: "How to read a failed data app run, what the common errors mean, when to re-run or delete a run, and what to send when you ask for help." canonical: "https://rig.so/guides/data-app-troubleshooting" format: markdown --- Search guides, references, playbooks…⌘K Browse guides # When a data app run fails A data app runs as a chain of steps, and a failing step usually stops the run there. Some steps may fail without stopping it, such as a post to Slack: the rest of the app carries on, and the run finishes with an amber **completed with errors** badge in place of a red failed one. This guide shows you how to find the step that failed, what the common errors mean, and what to do next. If you are new to data apps, read [Data apps: open, run, inspect and share](https://rig.so/guides/data-apps-basics) first. ## Read the failed run Open the app and pick the failed run in the run selector. In place of the report you get a red panel headed **Run Failed**. - The badge beside the heading reads **at** followed by the ID of the step that failed. A run Rig stopped before any step started has no badge, and neither does one that was cancelled, auto-expired or reaped (see the messages below), because no step recorded the failure. - Under it is the error itself. When the failed step is one that queries data, a line such as **Failed after 42.0s** says how long it ran before it stopped. - If some data steps finished and returned rows first, a **Partial Data Collected** box lists them. Steps that returned no rows, and steps that do not query data, are left out. Click one to see the rows it fetched. If Rig kept none of that step's rows, its button is greyed out and reads *No row data available* when you hover over it. - The **Execution Log** lists the steps that ran, with their status, and with their duration for steps that query data. Later steps never started, so they are not listed, apart from data steps that were running alongside the one that failed. Click a failed step to show its full error, and click the log heading to fold it away. The step ID and the error text are what everyone else will ask you for, so copy both before you do anything else. ## Errors you may see - **Pre-flight column check failed: column '…' does not exist**. A column the query relies on has been renamed or dropped in your warehouse. On Redshift and Postgres, Rig checks the columns before running each query, so that query scanned nothing, though earlier steps may already have run. Other warehouses report the same problem in their own words: Snowflake, for example, calls it an invalid identifier. Either way, the query in the app needs updating to the new column name. - **RBAC violation:**, usually followed by *Access denied*, the tables it refused and the schemas your role can use. A shorter form names a single table or schema your role is denied. The run reads data your role has not been granted. When you start a run yourself, a missing schema is usually caught earlier: an *Execution failed* message starting *Accessing workflow: Access denied* appears as you click Run Now, and no run is added. An owner can grant access in the Access Gateway; see [Admin: people, roles and access](https://rig.so/guides/admin-people-and-roles). - **Scheduled workflow blocked for creator role '…'**, followed by *Access denied* and the schema that was refused. A scheduled run reads data with the role of the person who created the app. Rig stopped this one before any step started, so the panel has no step badge and says *No execution log data available for this run.* The fix is a grant for the creator's role. If the role shows as **'unknown'**, the creator has left the workspace, which a grant cannot fix, so contact Rig support. - **Auto-expired: exceeded 30 minute timeout**. The run was still marked as running 30 minutes after it started, so Rig marked it failed when someone next opened it or started a new run of the app. - **Reaped: no progress heartbeat for …**. The run stopped reporting progress, so Rig marked it failed. Either the worker running it stopped or ran out of memory, or one step ran for a long time over a lot of data. A narrower date range or a filter often helps. - **Reaped: dispatched off-box but never started …**. Rig handed the run to a separate worker, and the worker never picked it up, so Rig marked it failed. Nothing in the app caused it, so run it again. - **Cancelled by user**. Someone clicked **Cancel** while the run was going. A cancelled run shows as a red failed run, so check this message before you look for a fault. - **A message that the query timed out**. The query ran longer than Rig allows and was cancelled. A narrower date range or a filter usually fixes it, which means editing the app. - **An error from a step that uses a language model**. The usual causes are a rejected provider key, an account out of credit, or a rate limit. [LLM & Billing](https://rig.so/guides/llm-and-billing) explains each one. Opening an app can go wrong in two other ways. If its creator has shared it with named people and you are not one of them, Rig treats it as if it does not exist: the page goes back to the list of apps with no message. Ask the person who built it to add you. A panel headed **You don't have access to this data app** means your role cannot read the data the app uses, or the app is limited to editors and above until its creator shares it. Under the reason it says *Please ask an admin to grant your role access to the underlying data.* A run that shows **You don't have permission to view this report** means the same for the data in that run. Missing data access is a change for an owner to make. When the reason says the app is limited to editors and above, ask its creator to share it with you instead. ## Old numbers, no error A run can succeed and still show yesterday's figures. Running an app queries your warehouse as it is, and if the source behind it has not synced, the warehouse has nothing newer to give. Check the source's status under **Connections** → **Connectors** before you look for a fault in the app. The sync status is shown to people who can manage connections, on a workspace where you manage your own connections; if you cannot see it, ask an owner. [Keep your data fresh](https://rig.so/guides/sync-and-freshness) explains the statuses and schedules. ## Re-run once Click **Run Now**. If the app takes parameters, the **Run Parameters** popover asks for them first. Some failures are temporary, such as a busy warehouse or a model provider under load, and a second run clears them. If it fails again at the same step with the same error, stop re-running: the cause is in the app or the data, and more runs will only repeat it. If you get **Run already in progress** instead, another run of the app is still going, so wait for it to finish first. ## Delete a bad run A failed or wrong run stays in the history until someone deletes it. With the run selected, click the bin icon in the toolbar (its tooltip reads **Delete run**) and confirm. - You can delete a run you started yourself. Editors and owners can delete any run, and so can Rig support. - A run that is still queued or running cannot be deleted. While it runs, the toolbar shows a red **Cancel** button in place of Run Now, Comments and the bin, so cancel it or wait for it to finish. - If you are not allowed, you see **Failed to delete run** and the run stays. The toolbar also has a **Delete app** button with the same bin icon. It removes the whole app and its run history once you confirm, so make sure you click the right one. Deleting an app needs the editor role or above; on other roles it fails with **Failed to delete app**. The bin that appears when you hover over a run in the run selector deletes that run straight away, without asking first. If the run you deleted was the one on screen, the app switches to the newest run that is left, whatever its status. If that one failed too, you will see another red panel rather than a report. Deleting a different run from the run selector leaves the one you are viewing in place. ## Fixing the app itself Changing the workflow behind an app, such as a renamed column, a tighter date range or a different prompt, needs the editor role or above. If you are an analyst or a viewer, pass the step ID and error to the person who built the app or to an editor. ## What to send when you ask for help What gets a failing app looked at fastest The name of the app, the step ID from the **Run Failed** badge if it has one, the full error text copied from the panel, and when it started failing, including whether a re-run fails the same way. Was this guide helpful? Yes No --- - [This page as HTML](https://rig.so/guides/data-app-troubleshooting) - [Site map for language models](https://rig.so/llms.txt) - [API and agent documentation](https://rig.so/developers)