Troubleshooting

Four questions people actually ask about a dashboard that stopped working, each answered as a procedure with the exact text Dashies puts on the screen.

Each section below starts from what you can see and narrows to one cause. Where Dashies prints a message, it is quoted here exactly, so you can search for the sentence you are looking at.

Why did it not refresh?

Start on dashies.xyz/app/schedules and find the dashboard. Where it is on that page is most of the answer.

It is not listed at all

Only dashboards with a connected data source appear. If yours is absent it has no refresh manifest, so there is nothing to re-run. The page says so in its empty state:

Dashboards become schedulable once they have a connected data source. Connect one in Data sources, or publish a data-backed dashboard from your AI tool, then set its cadence here.

Three ways a dashboard ends up here:

It was published as plain HTML. A dashboard published without a spec and a source is static by design. Republish it through your AI tool with a spec. See Author a dashboard.
The publish succeeded but the refresh manifest did not install. The dashboard is live at a real URL and stays static until it is republished. Your AI tool was told:
```
dashboard content was saved, but refresh installation failed - call get_dashboard_spec and republish with the returned spec_hash to complete.
```
It is a workspace dashboard bound to a personal data source. This is the most expensive version, because everything upstream succeeds. Read the workspace trap, which is the whole story and the fix.

A dry run does not catch case 3

dry_run stops before the manifest is installed, so a clean dry run is not evidence that the data source can be bound in the scope you are publishing into.

It reads Not scheduled

The cadence is manual, so it runs only when someone triggers it. Give it a cadence: Set and change a refresh schedule.

It reads Paused - plan lapsed

Runs are being skipped, not failed. Nothing is broken and nothing was deleted. The schedule is preserved and the next due run after an upgrade refreshes normally. See what a lapsed plan actually does.

It reads Paused or Archived

Someone set it that way. Pausing is also how you stop retries on a dashboard you know is broken.

It reads Failing

A run happened and it failed, so the dashboard is serving its last good numbers. Open History, select the dashboard, and read the reason on the newest run. The classified reasons and what each means are in what a failed run tells you.

It is already retrying. The Next run column shows when.

It reads Stale, with no failed run

Nothing errored and nothing ran. Check the scheduler caption above the tabs first:

Scheduler active means the engine is running and this dashboard was missed. If it stays missed you get an email, subject Refresh overdue:.
Scheduler may be delayed means the engine itself is behind, and no dashboard is refreshing. Nothing you change on this dashboard will help.

There is one more shape worth knowing, because it looks perfectly healthy: a next run set so far ahead that it will never fire. Dashies detects it and emails Refresh not scheduled:. Setting the schedule again fixes it.

On a team dashboard, check this before anything else

A workspace dashboard never shows Paused - plan lapsed. That verdict is computed from the plan of whoever is looking at the page, and on a team dashboard the plan that actually pays is the data source creator's. So a team dashboard whose data source owner has lapsed reads Stale, with no failed run and no indication anywhere that a plan is involved.

Where the real cause is visible depends on who you are:

If you published the dashboard, its run history shows the due runs as Paused, carrying a lapsed tier. That is the answer.
If a colleague published it, the History tab shows you nothing: it reads the run log directly, and that is readable only by whoever published the dashboard. Ask your AI for the dashboard's refresh status instead. get_refresh_status is workspace-capable and returns the recent runs to any member, so the paused runs are visible there even though the page shows none.

So the tell has to be the pattern rather than any one dashboard: every scheduled dashboard on that data source goes quiet at the same time, because they all key on the same person's plan. If several of your team's dashboards went stale together, find who created the data source they share and check whether their plan is still active. See whose plan is checked.

It reads Up to date but the numbers look old

Two possibilities, and the run history separates them:

The newest run is marked No change. The SQL re-ran and produced identical data. Your source data has not moved, or your query's time window is not relative to now.
The newest run succeeded with a row count. It refreshed, and what you are looking at is what your warehouse returned. Go to Why are the numbers wrong?

It is a few minutes past its next run

That is normal, not late. Runs are claimed on a grid and each dashboard carries a small fixed offset, so an anchored schedule fires within roughly 30 minutes of its displayed time. See the precision you actually get.

Why can I not refresh it on demand?

Run now on the Schedules page, and trigger_refresh from your AI tool, are both paid. What differs is who has to be paying.

Dashboard	Message
Personal	`Refreshing on demand requires a paid plan.`
Workspace	`This dashboard's data source is on a plan that no longer includes refresh. The member who connected it needs an active paid plan.`

On a workspace dashboard, upgrading your own plan does not clear it

The plan checked is the one belonging to whoever created the data source, which may be someone else entirely. The refusal currently renders a View plans button, and that button takes you to your plan, not theirs. Following it and upgrading will not make the refusal go away.

The fix is to find the member who created that data source and have them resubscribe, or to bind the dashboard to a data source created by someone whose plan is active. This is a known defect in the button, tracked as #832.

From an AI tool there is a second reason, unrelated to plans:

Triggering a refresh on demand isn't available for workspace dashboards yet - it works on personal dashboards only.

Use Run now in the web app for a workspace dashboard. Scheduled refresh of a workspace dashboard works normally, and so does reading its status. Every trigger_refresh refusal is listed on its reference page.

One more that reads like a failure and is not: a repeat trigger within 60 seconds of a previous attempt is coalesced and reports back as such, unless the last attempt failed. A retry seconds after a failure genuinely re-runs.

These three messages are quoted in more than one place

The same text appears on Set and change a refresh schedule and, for the tool refusals, on the trigger_refresh reference. They are quoted from the server rather than described, so if the message on your screen matches none of them, you are on a newer build than this page.

Why are the numbers wrong?

First separate wrong from old, because they have nothing in common.

1. Check when it last succeeded

Open History and select the dashboard. The freshness line says Updated 12m ago, or Last run failed 40m ago, or Refresh paused. If the last success is old, the numbers are not wrong, they are frozen. Go back to Why did it not refresh?

2. Look at what the run actually wrote

Click View on the newest successful run. That opens the data that run produced, exactly as it was stored. Compare two runs to see what moved.

3. Look at the query

View query on the Schedules row shows the SQL the refresh runs. This is the statement that produced the numbers, not a reconstruction of it.

On a workspace dashboard that control is not there. Ask your AI for the dashboard's source config instead, which returns the same compiled manifest and is readable by any member. See View query is personal dashboards only.

4. Cross-check one measure against your warehouse

Run the independent aggregate yourself and compare. The procedure is Verify your numbers, and it is the only step that can actually establish the numbers are right.

Once you know it is genuinely wrong rather than old, the cause is almost always one of these:

What you see	Likely cause
A total far larger than it should be	A non-additive measure being summed. Measure correctness
A total that is close but not equal	A join fanning out and double counting. Measure correctness
Numbers that are exact but for the wrong period	The time window in the SQL is absolute rather than relative to now
A filtered view disagreeing with the unfiltered one	The dataset mode cannot answer that filter exactly. Datasets and the four modes

Tiles are blank, or show dashes

That is a different failure from a wrong number, and it usually means the data arrived but could not be read. Look for this reason on the newest run:

island_unaddressable: the refreshed data is present but 3 declared keys would not resolve in it - main.month, main.ending_arr, main.__g_month. The previous data was kept. This usually means the statement's output column names no longer match the declared keys.

The refresh fetched real rows and then refused to publish them, keeping your previous data. It follows a change to the column names your statement returns. Republishing the spec re-derives the declarations against the current statement.

A single value rendered as - is a different thing again and is working as intended: the runtime shows a dash rather than a number it cannot render exactly. It never rounds a value into a wrong one.

Why can I not schedule it?

The Schedules page accepts the cadence, then the save fails with a message. Each one names the constraint.

The plan gate. Any cadence other than manual needs a paid plan:

a paid plan is required to schedule automatic refresh

Setting a schedule back to manual is always allowed, on any plan.

No data source. The dashboard has nothing to re-run:

this dashboard has no connected data source, so it cannot be scheduled to refresh; publish it with a data source via your AI tool first

Sub-hourly on a team dashboard. Not supported yet:

sub-hourly refresh is not supported on workspace dashboards yet

Permissions. You are not the owner, or not a member:

not authorized for this dashboard
not a member of this workspace

Interval out of range. Each cadence has its own allowed intervals:

an hourly interval must be every 1, 2, 3, 4, 6, 8, or 12 hours
a daily interval must be between every 1 and every 30 days
a weekly interval must be between every 1 and every 4 weeks
a monthly interval must be between every 1 and every 12 months
a sub-hourly interval must be every 15 or 30 minutes

Anchor out of range, or the wrong anchor for the cadence. The anchor fields differ per cadence, and supplying one that does not apply is refused rather than ignored:

hour must be between 0 and 23
day-of-week must be between 0 (Sunday) and 6 (Saturday)
day-of-month must be between 1 and 28
timezone must be a valid IANA timezone name
an hourly schedule does not take a day-of-week or day-of-month
a daily schedule does not take a day-of-week or day-of-month
a weekly schedule does not take a day-of-month
a monthly schedule does not take a day-of-week
a weekly schedule needs both a day-of-week and an hour
a monthly schedule needs both a day-of-month and an hour
a sub-hourly schedule does not take a day, time, or timezone

Why each limit exists is in cadences and intervals.

My AI tool cannot set the schedule I want

set_refresh_schedule takes no sub-hour argument, so an AI cannot set every 15 or 30 minutes however confidently it offers to. Use the Schedules page. Full argument list on the tool reference.

Why does it say connected but failing?

Because those are answers to two different questions, and both are true.

Active is what an explicit Test concluded. That test may be days old.
failing is what real refreshes have observed since.

The newer news is the health reading. The model, including why it takes two consecutive observations to flip and why timeouts are excluded, is on status and health are two different facts.

What you see on the data source card is the green Active pill with an amber note underneath. The note is phrased as an event, not a verdict, and it names the candidates worth checking rather than asserting one:

The last refresh of this data source was not authorized by the warehouse. Check its credentials and account access. It clears once a refresh succeeds.

The last refresh of this data source could not open a secure connection to the warehouse. Check the warehouse's TLS settings. It clears once a refresh succeeds.

The last refresh of this data source did not get a usable response from the warehouse. Check that the warehouse is reachable and not over its query limits. It clears once a refresh succeeds.

When the observation came from authoring rather than a scheduled refresh, the first clause reads The last request Dashies made to this data source and the last reads It clears once this data source is used successfully again.

What to do about it

1. Decide whether it still matters

Health records a past observation. If refreshes have succeeded since, the note is already gone. Check the dashboard's run history before changing any credential.

2. Read what the note actually names

not authorized covers a rejected credential and an account or billing problem on the warehouse side. did not get a usable response covers an unreachable host and being over a query quota. Rotating a working credential because of a quota problem is the mistake this wording exists to prevent.

3. Fix the cause, or test the data source

A passing Test clears the note immediately, including on a data source with no dashboards left on it. A failing Test sets the card to Error and leaves the health note alone.

Two things this reading does not mean:

It does not block anything. Health gates nothing. Refreshes, authoring and publishing all proceed exactly as they would without it.
It is not the same as the Error pill. Error means the last Test failed. Active with an amber note means the last Test passed and a real refresh since then did not.

Your AI tool sees the same pair. list_connections returns status and health_state as separate fields, described on its reference page.

Check it worked

Whatever you changed, confirm it the same way:

Trigger a run. Use Run now on the Schedules page, or ask your AI to trigger a refresh of a personal dashboard.
Open History and select the dashboard. A new run should appear at the top with a Succeeded status and a row count.
The dashboard's verdict should now read Up to date, and its freshness line Updated just now.
If you fixed a data source, its card should show Active with no amber note.
If an outage was open, a Refresh recovered: email arrives on the run that closes it.