Failure alerts and retries

When a scheduled refresh stops working, Dashies emails you rather than waiting for you to notice. This page is what arrives, who gets it, and how to control it.

Every alert comes from:

Dashies <alerts@send.dashies.xyz>

The policy behind the thresholds is on Plans and what is gated. This page is the artifact.

The eight subject lines

Four families, each opening with one email and closing with one. Subjects are distinct on purpose, so an escalation is never collapsed into the same inbox thread as the alert that opened it.

It refreshes from "Analytics prod", the data source you connected for the team.

What the failure email says

The first one leads with the count and the classified reason:

Your dashboard "arr-overview" has failed to refresh 3 times in a row.

Your warehouse rejected the connection sign-in. Reconnect it in Connections to resume refreshing.

The dashboard still shows the data from its last successful refresh.

Review the schedule and run history:
https://<handle>.dashies.xyz/app/schedules

You will not get an email for every failed run - one reminder if it is still failing in 7 days, and a short confirmation as soon as it refreshes successfully again.

On a dashboard with several datasets, the failing one is named in the opening line as (dataset "main").

The reminder is a different email, not a repeat. By the time it arrives you already know the dashboard broke, so it leads with how long the data has been frozen and whether waiting can help:

Your dashboard "arr-overview" has now failed to refresh 9 times in a row.

Its last successful refresh was on 2026-07-16 (UTC), 13 days ago.

Your warehouse schema changed since this dashboard was set up. Resync the connection in Connections to map the current columns.

This will not clear on its own. Retrying the refresh returns the same result until the cause above is fixed.

The dashboard is still serving the data from its last successful refresh.

Review the schedule and run history:
https://<handle>.dashies.xyz/app/schedules

We will check in again in 7 days if it is still failing, and confirm as soon as it refreshes successfully.

That last sentence appears only for failure kinds that genuinely cannot self-heal: a rejected credential, a TLS failure, a schema change, a removed data source, and a query that did not complete. A timeout or an unreachable host gets the weaker and still-true line instead:

It has not recovered on its own in that time.

Where a date, a duration, or a count is not known, that sentence is dropped rather than filled with a placeholder.

The reminder interval

One reminder per interval while the outage stays open. The interval is seven days, or one full period of that dashboard's cadence, whichever is longer:

A slow dashboard is never reminded about more often than it can attempt to run.

Overdue and not-scheduled

These two are the alerts you get when there is no failure to report. Nothing errored, so the failure machinery has nothing to fire on, and the dashboard looks entirely healthy in every surface.

Overdue means the scheduler has not reached the dashboard since it was due. It fires once the lateness passes three of that dashboard's own periods, floored at one hour and capped at seven days:

Your dashboard "arr-overview" has not refreshed for 3 days past its due time.

No refresh has run and no error was recorded: the scheduler has not reached this dashboard. It still shows the data from its last successful refresh.

Review the schedule and run history:
https://<handle>.dashies.xyz/app/schedules

This is the only email about this delay. A short confirmation will follow when the dashboard refreshes again.

Not scheduled is the opposite failure. The next run is set further ahead than the cadence could ever produce, so the dashboard is frozen while presenting as active:

Your dashboard "arr-overview" is not going to refresh.

Its next refresh is set so far ahead that it will effectively never run, which is not something its schedule could produce on its own. The dashboard still shows the data from its last successful refresh.

Set the schedule again on the Schedules page to start it refreshing.
https://<handle>.dashies.xyz/app/schedules

This is the only email about this. A short confirmation will follow once the dashboard refreshes again.

Setting the schedule again is the whole fix. See Set and change a refresh schedule.

Both close with Refresh back on schedule: <slug>, which is worded neutrally because one composer closes both: it says the dashboard is refreshing again and the latest run succeeded, and claims nothing about a delay that may never have existed.

The retry ladder

A failed run does not strand a dashboard and does not retry at full rate. The wait doubles from five minutes and stops at one full period of that dashboard's own cadence.

The ladder stops at whichever cap applies, and on the faster cadences that happens early. An hourly dashboard caps at 1 hour, so its fifth failure waits 60 minutes rather than the 80 the doubling would give. A daily dashboard reaches 80 minutes and keeps doubling from there.

For every cadence except sub-hourly the cap is one full period, which is the base unit multiplied by the every-N interval.

So a permanently broken daily dashboard retries about once a day rather than dozens of times, and a broken hourly one retries hourly. The next attempt is shown in the Next run column while the row reads Failing.

A success resets the count to zero and re-anchors the schedule normally.

What never sends a failure alert

• A plan lapse. Runs are skipped rather than failed, so the failure machinery never fires. You get the Refresh paused notice instead, and a lapse does not count as the recovery that closes an open outage.
• A muted dashboard. Muting leaves the outage state untouched, so unmuting during one does not fire a backlog.
• A free plan. No email is sent, but the outage is still tracked, so upgrading mid-outage alerts on the next failure rather than swallowing it.
• A run skipped because the dashboard was being republished at that moment. That is not a failure and is re-attempted on the next eligible run.

Change the threshold

On a free plan this section reads:

Failure alert emails are a Pro feature. Dashies can email you when a scheduled refresh keeps failing, and once more when it recovers.

Mute one dashboard

Muting stops the emails. It does not stop the retries, and the dashboard still reads Failing on the Schedules page, because the numbers on it are still frozen.

A muted dashboard carries a struck-through bell on its Schedules row:

Failure alerts are muted for this dashboard. Turn them back on in Set schedule.

A dashboard with an open outage carries an amber bell instead:

Emailed you 2h ago after 3 consecutive failures. This dashboard has not refreshed successfully since.

Check it worked

1. Open Settings, then Alerts. The threshold shows the value you picked, and any dashboards you muted are listed.
2. Confirm the alert address is not being filtered. Search your mail for alerts@send.dashies.xyz.
3. To confirm the delivery path end to end without breaking anything, wait for a real failure rather than manufacturing one: rotating a warehouse credential to a wrong value will alert, but it also stops every other dashboard on that data source.
4. On the Schedules page, a dashboard you have muted shows the struck-through bell on its row. Hover it to confirm the tooltip above.