--- title: Failure alerts and retries description: The eight emails Dashies sends about a refresh, who receives each one, how a failed run backs off, and how to change the threshold or mute a dashboard. updated: 2026-08-05 tier: pro --- 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: ```text Dashies ``` The policy behind the thresholds is on [Plans and what is gated](/concepts/plans-and-gating#failure-alerts). 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. | Subject | Sent when | Goes to | |---|---|---| | `Refresh failing: ` | The consecutive-failure count reaches your threshold. | The person who published the dashboard | | `Still failing: ` | The same outage is still open one re-alert interval later. | The person who published the dashboard | | `Refresh recovered: ` | A run records a real success and closes the outage. | The person who published the dashboard | | `Refresh overdue: ` | The scheduler has not reached the dashboard since it was due. | The person who published the dashboard | | `Refresh not scheduled: ` | The next run is set so far ahead it will effectively never fire. | The person who published the dashboard | | `Refresh back on schedule: ` | A successful run closes an overdue or not-scheduled episode. | The person who published the dashboard | | `Refresh paused: ` | The plan paying for the refresh no longer includes it. | **The person whose plan lapsed** | | `Refresh resumed: ` | That plan is upgraded and refresh restarts. | **The person whose plan lapsed** | :::warning{title="The last two go to a different person on a team dashboard"} For a personal dashboard the two people are the same, and nothing differs. On a **workspace** dashboard refreshing from a warehouse, the plan that pays belongs to whoever created that data source, who may never have opened the dashboard. So the pause and resume notices go to them, not to whoever published it, and they name the data source so a recipient with several warehouses knows which one is involved: ```text It refreshes from "Analytics prod", the data source you connected for the team. ``` Everything else on the list still goes to the publisher. See [whose plan is checked](/concepts/connections-and-scope#whose-plan-is-checked). ::: ## What the failure email says The first one leads with the count and the classified reason: ```text 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://.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")`. :::note{title="The email says Connections; the app says Data sources"} These are the same page. The email copy still uses the older word. Open [dashies.xyz/app/connections](https://dashies.xyz/app/connections), or the account menu, then **Data sources**. ::: **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: ```text 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://.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: ```text 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**: | Cadence | Reminder interval | |---|---| | Sub-hourly, hourly, daily, weekly | 7 days | | Every 2 weeks | 14 days | | Monthly | 30 days | | Every 3 months | 90 days | 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: ```text 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://.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: ```text 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://.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](/guides/refresh-schedule). Both close with `Refresh back on schedule: `, 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. | Consecutive failures | Wait before the next attempt | |---|---| | 1 | 5 minutes | | 2 | 10 minutes | | 3 | 20 minutes | | 4 | 40 minutes | | n | `5 minutes x 2^(n-1)`, until it reaches the cap | **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. | Cadence | Cap | Reached at | |---|---|---| | Sub-hourly, every 15 or 30 minutes | **1 hour** | 5th failure | | Hourly | 1 hour | 5th failure | | Every 4 hours | 4 hours | 7th failure | | Daily | 1 day | 10th failure | | Weekly | 7 days | 12th failure | | Every 2 weeks | 14 days | 13th failure | | Monthly | 30 days | 15th failure | For every cadence except sub-hourly the cap is one full period, which is the base unit multiplied by the every-N interval. :::note{title="Sub-hourly is the exception, and it backs off further than one period"} A sub-hourly schedule caps at **1 hour**, not at its own 15 or 30 minutes, because the backoff is computed from the hourly base without the sub-hour selector. So a broken 15-minute dashboard retries hourly, which is four of its periods rather than one. That is deliberate and errs toward retrying less. It also means a sub-hourly dashboard that recovers can be up to an hour behind rather than 15 minutes. ::: 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 :::steps ### 1. Open Settings, then Alerts The section is headed **Refresh alerts**. ### 2. Pick a threshold **Alert after this many consecutive failures** offers **2**, **3**, or **5**. The default is 3. It applies to every dashboard you own. ### 3. It saves as you pick it There is no save button. A value set outside those three through the API is shown underneath as `Currently set to N failures.` so the picker never looks silently wrong. ::: On a free plan this section reads: ```text 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 :::steps ### 1. Open the Schedules page [dashies.xyz/app/schedules](https://dashies.xyz/app/schedules). ### 2. Open the dashboard's Set schedule dialog At the bottom sits a switch labelled **Email me if a scheduled refresh fails**. Turning it off mutes that dashboard. It writes immediately and does not wait for Save schedule. ### 3. Unmute from either place The same switch, or the **Muted dashboards** list under Settings, then Alerts, where each muted dashboard has an **Unmute** button. When none are muted the list reads `No dashboards are muted. Failure alerts are on for all of them.` ::: :::note{title="Muting is personal dashboards only"} The switch is not shown on a workspace dashboard. There is no per-dashboard mute for a team dashboard today, so its alerts follow the publisher's threshold. ::: 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: ```text 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: ```text 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.