Monitor refreshes

Everything that refreshes on a schedule is on one page: dashies.ai/app/schedules. This is how to read it.

A dashboard only appears there once it has a connected data source. A static dashboard has nothing to re-run, so it is absent rather than listed as idle.

The four things on the page

Top to bottom:

Surface	Answers
The attention band	"Is anything broken right now?"
The scheduler caption	"Is the refresh engine even running?"
The tabs and table	"What is each dashboard doing?"
The History tab	"What actually happened, run by run?"

The attention band

The band sits above everything else and lists only the dashboards that are Suspended, Failing or Stale. It shows at most three, then a count of the rest.

Everything else is deliberately absent. A paused or archived dashboard is doing what it was told to, so listing it as needing attention would turn an exception feed into a second copy of the table.

When nothing is wrong the band collapses to one line:

All 12 dashboards are refreshing on schedule. Next refresh in 24m.

Each listed dashboard gets its name, its slug, a state line, and a Run now button. The state line separates a first miss from a stuck job, because those need different reactions:

The last refresh failed. Last updated 2h ago.
6 refreshes in a row have failed. Last updated 2w ago.
Last updated 3d ago, which is past its refresh interval.
Dashies stopped scheduling this dashboard after repeated failures. Last updated 2w ago.

The last of those is a Suspended dashboard. It leads with the stop rather than with a count, because the count is the part that changes nothing about what you do next.

A dashboard that has never completed a run reads Has never refreshed in place of the Last updated clause.

A lapsed plan is reported separately. When that is the only thing wrong, the band is replaced entirely by a banner counting the paused dashboards, with a link to resume them.

The table's default sort is Problems first, which orders it by the same urgency the band uses, so the band's dashboards are also the table's top rows. Switching the sort to Next run, Last run, or Name breaks that alignment on purpose, and the band stops claiming the rows are listed below.

The scheduler caption

Under the band, one line reports whether the refresh engine itself is alive:

Scheduler active - last swept 3m ago

Past 20 minutes it turns amber and reads Scheduler may be delayed. The line is hidden entirely when the heartbeat cannot be read.

This distinguishes the two failures that look identical from a dashboard row: the scheduler is running and your dashboard is broken, or the scheduler is not running and every dashboard is frozen. If the caption is amber, nothing is wrong with the dashboards.

The Data column

Every row carries exactly one verdict. It answers "can I trust these numbers", not "does a schedule exist", so there is no green "Active" that stays true while something else is wrong. The most severe applicable verdict wins.

Verdict	Meaning	What to do
Suspended	Dashies has stopped scheduling it after repeated failures. Nothing will run until it is resumed.	Resume it
Failing	The last run failed. The dashboard is serving its last good numbers.	Troubleshoot it
Archived	Deliberately idle.	Nothing.
Paused	Deliberately idle.	Nothing.
Paused - plan lapsed	Runs are being skipped, not failed.	Upgrade, and it resumes on its own.
Not scheduled	The cadence is manual. It runs only when triggered.	Set a cadence if you want one.
Awaiting first run	Scheduled, never completed a run yet.	Wait for the next run, or use Run now.
Stale	The last good run is older than twice this dashboard's own period.	Troubleshoot it
Up to date	Refreshing normally.	Nothing.

Stale is scaled to the dashboard, not to a fixed age. An hourly dashboard and a monthly one are judged on their own periods, so a daily dashboard that ran 26 hours ago still reads Up to date. The window is two full periods, which absorbs normal timing spread and one skipped run before it says anything.

Suspended outranks Failing, and the difference matters. Failing means the job is broken and will retry; Suspended means we have stopped trying. A suspended row shows None in Next run, and hovering that cell names the failure class and what to do:

Dashies stopped scheduling this dashboard after repeated failures it could not get past. Fix the cause and run it now, or resume the schedule from this row's menu.

The row filter groups Suspended under Failing, so a reader looking for broken schedules finds both in one place. The rule that stops a schedule, and the four things that start it again, are on Suspended schedules.

Under the verdict sits the freshness line for the most recent run. Each state is worded differently on purpose, so a failed or in-flight run never reads as Updated 5m ago:

Updated 12m ago
Refreshing now
Last run failed 40m ago
Refresh paused

Relative times are compact throughout: just now, 12m ago, 2h ago, 3d ago, 2w ago. In the run history, hovering a run's Started cell or one of the health-strip dots gives the exact timestamp.

The Next run column, and what it shows while failing

For a healthy schedule this is the next nominal run time. For a Failing row it is the next retry, which is not the same thing: retries back off, so the retry instant moves further out with each consecutive failure. When the retry is imminent, or the server has not yet materialized an instant, the cell reads Retrying shortly.

The ladder itself is on Alerts, channels and retries.

A Suspended row has no next run at all and reads None.

Reading the History tab

History replaces the table with a newest-first feed of runs. Filter it by All, Succeeded, Failed, or Running. It loads 100 runs at a time.

Selecting a dashboard drills into that dashboard alone and adds a header with:

• the freshness line for its latest run,
• N/M recent runs succeeded, over the most recent 30 runs. Runs still in flight and plan-lapse skips are excluded from both halves, because neither is a failure,
• a strip of up to 10 dots, oldest on the left, one per recent run.

Each run row carries Status, Started, Duration, and Rows.

Status pill	Means
Succeeded	The refresh completed and wrote data.
Failed	The refresh did not complete. The previous data was kept.
Running	In flight.
Paused	Skipped because the plan paying for this dashboard's refresh lapsed.

Paused is neutral, not red, and does not count as a failure. The row is recorded as a failed run carrying tier_lapsed, and every surface that reads it de-reddens it on that basis: the pill, the dot in the health strip, and the success ratio all treat it as neither a success nor a failure. See what a lapsed plan actually does.

Two markers appear in the Rows cell:

• No change means the SQL re-ran and produced data byte-identical to the previous run. It is a healthy result, not a missed refresh. It appears only on an explicit determination, never when the comparison is unknown.
• A signed delta such as +412 or -8 is the row-count change against the previous counted run of that dashboard. It is deliberately not colored: a shrinking cube is not a failure. It appears in the per-dashboard drill-in only, because counts from different dashboards are not comparable.

What a failed run tells you

A failed run expands into a detail line beneath it. What you see depends on where the failure came from.

A warehouse-backed run carries a classified reason and, for most classes, a remedy link:

Class	Line shown
connection_auth	The warehouse sign-in for this data source did not succeed. If its password or key changed, enter the new one on the data source in Data sources. A login that no longer exists needs the data source added again, and the dashboard published against it.
connection_unreachable	The refresh could not use your warehouse data source. The warehouse may be unreachable, refusing connections, or returning errors of its own. Check the data source in Data sources.
connection_timeout	The refresh stopped before your warehouse returned data. A slow warehouse, a heavy query, or a cancellation by the warehouse itself all report this way. Check the data source in Data sources.
ssl_failed	The secure connection to your warehouse could not be established. Check the certificate and the encryption settings the database presents. If it is a PostgreSQL data source whose certificate is not publicly signed, you can instead turn off the certificate check in Data sources.
schema_drift	The warehouse could not find an object or column this dashboard reads. A table or column that was renamed or dropped reports this way, and so does a query asking for a name it does not return. Some warehouses report an object the login cannot read the same way, so if the object still exists, check that the login this data source uses can read it. Otherwise correct the query and publish the dashboard again. On a PostgreSQL data source not added as only accepting known IP addresses, press Resync schema in Data sources before correcting the query, so the tables and columns Dashies shows your AI tool are current.
cube_error	This dashboard's query did not complete against your warehouse. A schema or permission change, or a result too large to return, reports the same way as a query error. Check the recorded reason before republishing the query.
connection_removed	The warehouse this dashboard refreshed from was removed. Add a replacement data source in Data sources, then publish the dashboard against it.
tier_lapsed	Paused - the plan that pays for this dashboard's refresh no longer includes it. Refreshing resumes automatically once that plan is upgraded.
extractor_host	The refresh failed inside Dashies rather than at your data source. Nothing in the data source or the query needs changing. Check the recorded reason for which part of the refresh failed.
audit_refused	A check on the new data was not satisfied, so this dashboard is still serving the previous version. The recorded reason names which check refused and what it compared. What to do next depends on which one it was.

A class this build does not recognize falls back to a line that asserts nothing about the cause:

The scheduled refresh could not recompute this dashboard's data. Check the recorded reason for what failed.

A run against the built-in self source carries no class. It shows a plain readable sentence instead, with the raw server text behind Show details.

The stored reasons for a warehouse failure are a fixed, closed set. These are the literal strings a run records:

warehouse connection authentication failed
warehouse was unreachable
warehouse query timed out
warehouse TLS/SSL negotiation failed
warehouse cube query failed
data connection is no longer active
the plan that pays for this dashboard's refresh has lapsed; paused until it is upgraded
warehouse schema changed; cube query no longer matches
the Dashies extraction service failed; this is ours, not your warehouse
the data this refresh produced did not pass its checks against the previous version, so the dashboard is still serving the last version that did

They never carry your warehouse's host, user, database name, or any driver text. That is deliberate: a run row is not a safe place to keep remote error output.

One reason is longer, and it is the one worth recognizing on sight:

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.

That run fetched real data and then refused to publish it, because the keys the dashboard reads would not have resolved and every tile would have rendered empty. Your previous numbers were kept. It usually follows a change to the column names your SQL returns.

What was sent about a run, and whether it arrived

Open a run's permalink and, where Dashies decided to alert about it, the page carries a short timeline. Each line is one decision, with the time it was taken and a sentence saying what it was:

2h ago   Alert raised: this refresh failed on our side, not on your data source.
1d ago   Failure alert raised after 3 consecutive failures.

Beside each sentence sits one chip per delivery, saying per channel what came of it. A chip per delivery rather than per channel, because an email alert resolves one delivery per recipient:

Chip	Means
Email delivered	The mail provider accepted it.
Slack delivered	Slack accepted it and returned a message id.
Email queued	Not yet attempted, or waiting out a backoff.
Email failed	An attempt failed and it will be tried again.
Slack failed, no more attempts	Every attempt was used and nothing further is coming.
Email not sent, daily limit reached	The recipient's ten-a-day limit was already spent.

Hover a chip for when it landed, why it did not, and how many attempts it took.

A line with no chips is normal and does not mean nothing arrived. The line itself is written on the first confirmed delivery, so its presence already says something was sent. The chips are a separate, newer record, and every alert raised before the queue existed has none, which reads as "no per-channel record for this one" rather than as a failure.

Seeing what a run produced

A successful run that stored a snapshot gets a View button in its row. It opens that run's data exactly as it was written, so you can compare two runs, or compare one run against your warehouse, without republishing anything.

A run whose dataset offloaded to Parquet has no button, because there is no JSON snapshot to open.

To see the SQL behind a dashboard, use View query in its row on the Schedules table.

From your AI tool

Ask for the refresh status by slug, and your AI reads the same state plus the recent runs:

What is the refresh status of my arr-overview dashboard?

That calls get_refresh_status, which returns the schedule, the next run, the consecutive-failure count, and the most recent runs. It never triggers a refresh.

Check it worked

1. Open dashies.ai/app/schedules. The scheduler caption reads Scheduler active with a sweep within the last few minutes.
2. The band either lists dashboards by name or collapses to the all-clear sentence. If it lists any, each one has a reason and a link.
3. Open History and confirm runs are landing. The newest run's Started time should be no older than the shortest cadence you have set.
4. Pick one successful run and click View. You should see the data that run wrote.