Troubleshooting

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.ai/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:

1. 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.

2. 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.

3. It is a dashboard bound to a data source from a different workspace. This is the most expensive version, because everything upstream succeeds. Read the workspace trap, which is the whole story and the fix.

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 Suspended

Dashies stopped scheduling it. This is not another way of saying Failing: it means the retries have stopped too, so waiting will not help.

It happens when a dashboard fails enough consecutive scheduled runs, for a cause you can fix, over at least a week. One message was sent when it happened:

Refresh suspended: <slug>

Fix the cause first, then start it again. A refresh that succeeds turns the schedule back on by itself, so Run now is usually the whole fix. If you would rather clear the state without running anything, use Resume schedule on the row menu, on the dashboard's schedule page, or on the Issues page. Full rule and every way back: Suspended schedules.

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.

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, and the payer is the workspace the dashboard lives in:

Refreshing on demand requires a paid plan on this workspace. Only a workspace admin can change the plan.

From an AI tool there is a second reason, unrelated to plans - refreshing a workspace dashboard rewrites its data, so it takes the same permission as republishing it:

You hold a view-only role in this workspace, so you cannot publish, change or refresh its dashboards. A workspace admin can change your role.

Ask a colleague who can publish to the workspace, or to change your role. Run now in the web app applies the same rule, so switching to it will not help - it just words the refusal for a browser (your role in this workspace is view-only). 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.

Why are the numbers wrong?

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

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

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

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

Why each limit exists is in cadences and intervals.

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

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.

Why did I not get an alert?

Something broke, the Schedules page agrees, and nothing arrived. Work down this list: each step rules out one layer, and the run's own page settles it at the end.

1. Was a message even owed?

An alert fires on the threshold, not on the first failure, and the default is three consecutive failures. Check Settings, then Alerts. A dashboard that failed twice is behaving exactly as configured.

A muted dashboard sends nothing about failures at all. Its Schedules row carries a struck-through bell. The one exception is a suspension notice, which is sent whatever the mute says.

On a free plan nothing is sent, on either channel.

2. Is the category switched off?

A workspace admin can switch off a whole family per channel under Settings, then Notifications. A refresh failure is in Refresh failures; a failure on our side is in Platform incidents, which is a different row, so switching one off does not silence the other.

Workspace security only exists on Enterprise. On any other plan the row is absent rather than off.

3. Is your own email switched off?

Under Settings, then Alerts, My channels carries one switch, Email me about my dashboards. It is the last word: turning it off stops every alert email to you whatever a workspace admin has set. If it is off, the pane says when:

Alert emails are off. You turned them off on 2026-09-01, here or from the unsubscribe link in an alert email. Switching this back on undoes that.

It does not say which of the two turned it off, deliberately. The switch on this pane and the unsubscribe link in an email write the same thing, and nothing records which one it was. Switching it back on undoes either.

4. Was the daily limit already spent?

Ten messages per recipient per 24 hours, counted across Refresh failures and Platform incidents together. Past that, further messages in those two categories are recorded rather than sent. Open the run's permalink and look for the chip:

Email not sent, daily limit reached

Every other category is exempt, so a suspension notice or a billing notice still arrives on a day the limit is spent.

5. Did the send fail?

Open the run's permalink. Each alert line carries one chip per delivery, and the chip says what happened: Email delivered, Email queued, Email failed, Slack failed, no more attempts. A failed send is retried on a widening ladder for up to six attempts, so queued and failed both still have a future.

See what was sent about a run.

Nothing arrives in Slack

Four different things, and the pane distinguishes them:

The card says	What it means
Not connected. Alerts for this workspace go to email only.	No install. Press Add to Slack.
Connected, but alerts have nowhere to post. with an amber No channel pill	Installed with no destination. Press Pick a channel.
Dashies cannot post to Slack right now. with a red broken pill	Slack refused. See below.
The Slack column in the matrix is off	The category is switched off for Slack even though the channel is fine.

A broken card names the reason Slack gave, and there are two shapes of fix. If the app was removed from Slack or the token revoked, press Reconnect to Slack and go through the Allow screen again. If the channel was archived or deleted, the install is fine and Change channel is the fix. Nothing is lost in the meantime: a message that cannot be posted is retried, and the run page records every attempt.

Full walkthrough: Slack alerts.

Check it worked

Whatever you changed, confirm it the same way:

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