--- title: Alerts, channels and retries description: Every alert Dashies sends, the category it belongs to, who receives it, how email and Slack are chosen, and what stops a schedule that keeps failing. updated: 2026-09-11 tier: pro --- When something a dashboard depends on stops working, Dashies tells you rather than waiting for you to notice. This page is what arrives, who gets it, which channel it takes, and how to change any of that. Every alert email comes from: ```text Dashies ``` Nobody reads replies to that address. Every message points at the page in the app that can answer the next question instead. The policy behind the thresholds is on [Plans and what is gated](/concepts/plans-and-gating#failure-alerts). This page is the artifact. ## What Dashies sends Twenty messages, grouped into seven categories. Each family opens with one message and, where the situation can close, closes with one. Subjects are distinct on purpose, so an escalation is never collapsed into the same inbox thread as the message that opened it. | Subject | Sent when | Category | Goes to | |---|---|---|---| | `Refresh failing: ` | The consecutive-failure count reaches your threshold. | Refresh failures | The person who published the dashboard | | `Still failing: ` | The same outage is still open one re-alert interval later. | Refresh failures | The person who published the dashboard | | `Refresh recovered: ` | A run records a real success and closes the outage. | Refresh failures | The person who published the dashboard | | `Refresh overdue: ` | The scheduler has not reached the dashboard since it was due. | Refresh failures | The person who published the dashboard | | `Refresh not scheduled: ` | The next run is set so far ahead it will effectively never fire. | Refresh failures | The person who published the dashboard | | `Refresh back on schedule: ` | A successful run closes an overdue or not-scheduled episode. | Refresh failures | The person who published the dashboard | | `Data source failing: ` | A warehouse connection starts failing. One message per connection, not one per dashboard on it. | Data source health | The data source's owner and every workspace admin | | `Data source recovered: ` | That connection works again. | Data source health | The data source's owner and every workspace admin | | `Refresh suspended: ` | Dashies stops scheduling a dashboard that kept failing. | Suspended schedules | The person who published the dashboard | | `Refresh paused: ` | The plan paying for the refresh no longer includes it. | Billing | **The data source's owner and every workspace admin** (see below) | | `Refresh resumed: ` | That plan is upgraded and refresh restarts. | Billing | **The data source's owner and every workspace admin** (see below) | | `Payment failed for ` | A renewal charge did not go through. | Billing | The plan's owner, or every admin of the workspace holding it | | `Payment received for ` | A later charge on the same episode succeeded. | Billing | The plan's owner, or every admin of the workspace holding it | | `Refresh delayed on our side: ` | The refresh failed inside Dashies rather than at your warehouse. | Platform incidents | The person who published the dashboard | | `Query host not answering` | A query host serving a workspace's dashboards stopped answering. | Platform incidents | Every admin of that workspace | | `Query host answering again` | That host is answering again. | Platform incidents | Every admin of that workspace | | `Security: in ` | An admin change, member removal, SSO or domain change on an Enterprise workspace. | Workspace security | Every admin of the workspace | | `Refresh stopped: ` | A refresh stopped rather than publish rows carrying a value nobody is granted. | Row-level security refusals | The person who published the dashboard, and every workspace admin | | `Showing data as of : ` | The dashboard has more data than was ready for it, so it keeps the numbers it already had. | Platform incidents | The person who published the dashboard, and every workspace admin | | `Up to date: ` | That clears and the dashboard is current again. | Platform incidents | The person who published the dashboard, and every workspace admin | The two query-host subjects name the workspace whose host it is, where that name was carried, as `Query host not answering: `. The security subject names what happened when every change in the message is the same kind, and gives a count without a kind when they are mixed, because "3 admin roles granted" would be a lie about a group that also removed somebody. **`Showing data as of ` is not a failure either.** It arrives when a dashboard has grown past what was ready for it, so the refresh kept the numbers it already had rather than serving nothing. Nothing on your side needs changing, a coming refresh carries the new data, and `Up to date` follows when it clears. With no successful run to date the subject degrades to `Showing earlier data: `, because there is no date to name. **`Refresh stopped` is the odd one, and it has its own category for a reason.** It belongs to per-viewer entitlement rather than to refresh health: it fires when a dashboard filters rows per viewer and a refresh produced a value nobody is granted, so Dashies stopped rather than publish rows no viewer could ever see. Nothing was published and the dashboard still shows its last successful refresh. The message names up to five of the offending values and how many rows they account for, and the fix is to grant those values to somebody or list them as hidden values on that dataset, then refresh. Because it is a separate category, switching the refresh-failure family off does not silence it. :::warning{title="Refresh paused and Refresh resumed are about a plan, not about the dashboard's author"} On a dashboard refreshing from a warehouse, the plan that pays is the **workspace's**, not one held by whoever created the data source. So what these two notices report is the workspace's plan lapsing or resuming, and they name the data source so a recipient with several warehouses knows which one is involved: ```text It refreshes from the team's "Analytics prod" data source. ``` **Two audiences get the same email, and it is worded to be true for both.** It goes to the data source's owner, because it is their warehouse that stopped refreshing, and to **every workspace admin**, because changing a workspace plan is something only an admin can do. The two overlap often and are deduplicated when they do, so an admin who owns the data source gets one email and not two. The notice therefore says *this workspace's plan*, never *your plan*, and it says plainly that only an admin can change it. **Receiving one tells you nothing about what you can do in any OTHER workspace**, and a plan on one of those is not what lapsed and will not restart this refresh. See [whose plan is checked](/concepts/connections-and-scope#whose-plan-is-checked). ::: ## The seven categories A category is the unit you switch on and off. It groups the kinds that answer one question, so switching one off never silences another. | Category | Covers | Off means | |---|---|---| | **Refresh failures** | A scheduled refresh failed repeatedly, and the message when it recovers. | Nobody is told a dashboard broke. | | **Data source health** | A warehouse connection stopped answering, and the message when it works again. | Nobody is told a warehouse broke. | | **Suspended schedules** | Refreshing stopped for a dashboard that kept failing. | Nobody is told, and there is no follow-up message. | | **Billing** | A payment did not go through, and a plan that lapsed or resumed. | Nobody is told a renewal failed. | | **Platform incidents** | A refresh failed for a reason on our side. Covers our extractor, our publish gate and the query host. | Nobody is told when the fault is ours. | | **Workspace security** | Single sign-on disconnected, a domain released, a member removed, and a member made an admin. | Nobody is told about an admin change. | | **Row-level security refusals** | A refresh stopped rather than publish rows carrying a value nobody is granted. | Nobody is told, and there is no follow-up message. | **Workspace security is Enterprise only.** It is hidden from the matrix on any other plan. **Seven is what you can switch, and it is the whole of what reaches you.** Dashies also alerts its own operators, on a separate internal category that is never routed to a workspace or a person and never appears in the matrix. When a query host runs short of room, somebody here is told as well as you. There is nothing to configure and nothing you are missing: those messages are addressed to us. **A workspace admin sets the matrix.** Open Settings, then **Notifications** under the workspace's own group. Each category has a switch per channel, email and Slack. The entitlement is re-checked when the alert fires, so a category stored while a plan was current stops sending when that plan lapses. **Suspended schedules and Row-level security refusals are the two worth leaving on.** Neither has a reminder or a follow-up, so switching either off is not "fewer messages", it is nobody being told that a dashboard has stopped refreshing for good. **One switch on the same pane widens the audience rather than narrowing it:** ```text Copy every admin on failure alerts Admins of this workspace also receive the alert for a dashboard somebody else authored. ``` It is off by default. It governs the messages whose subject is a dashboard and whose audience is otherwise the author alone: `Refresh failing`, `Refresh recovered`, `Refresh overdue`, `Refresh not scheduled`, `Refresh back on schedule` and `Refresh delayed on our side`. **Some messages about a dashboard reach every admin whatever this switch says**, because each reports something an admin may have to act on rather than a run that failed: `Still failing`, `Refresh suspended`, `Refresh stopped`, and the pair `Showing data as of ` and `Up to date`. So do data source health, billing, query-host and security notices, where an admin is often the only person who can act at all. ## Channels An alert can take two channels, and they are chosen at different levels. ### Email, per person Email is addressed to people, so the last word is the recipient's. Under Settings, then Alerts, **My channels** carries one switch: ```text Email me about my dashboards Covers refresh failures, data sources, suspended schedules, billing and platform incidents. Turning this off stops all of them, whatever a workspace admin has set. ``` Every alert email also carries a one-click unsubscribe, both as a link in the message and as the standard headers a mail client reads. The headers name two routes, a web address and a mailbox, so a client that supports either can offer its own **Unsubscribe** control instead of making you open the message and find the link. **Whether your client shows one is its decision, not ours.** Gmail in particular gates the button beside the sender name on its own automated eligibility checks, which weigh sending reputation and volume rather than the shape of a header, so the headers alone do not put it there. The link inside the message always works. Following either asks once and then confirms: ```text Turn off Dashies alert email? This turns off every kind of Dashies alert email to your account: refresh failures, data source health, suspended schedules, billing and platform notices. ``` **Turning it back on is the same switch.** Open Settings, then Alerts, and turn **Email me about my dashboards** back on. The pane says when it was turned off and that switching it back on undoes that. The switch is on the paid part of the pane, so a lapsed plan hides it until the plan is current again. Unsubscribing changes nothing about your dashboards and does not stop anyone else being alerted. ### Slack, per workspace Slack is addressed to a channel rather than to a person, so there is no per-user Slack switch. One Slack channel is connected per workspace, installed by an admin from that workspace's **Notifications** pane. Full walkthrough: [Slack alerts](/operate/slack-alerts). ## The daily limit **Ten messages per recipient per 24 hours**, counted across the **Refresh failures** and **Platform incidents** categories together. Past that, further messages in those two categories are recorded as skipped rather than sent, and the run page says so. Every other category is exempt, including **Suspended schedules**, because that one has no reminder: a skipped message there would be permanent silence about the one thing you most need to know. ## Suspended schedules A schedule that cannot pass is eventually stopped rather than retried forever. Dashies stops scheduling a dashboard when **both** of these are true: 1. **The count.** Consecutive failed **scheduled** runs reach `greatest(5, your threshold + 1)`. With the three thresholds the app offers that is 5, 5 and 6. It is always at least one more than your alert threshold, so you are always told it is failing before you are told it has stopped. 2. **The clock.** The outage has been open for at least one re-alert interval, which is seven days for anything up to a weekly cadence and one full period for slower ones. **Only failures you can fix count toward the first.** The classes that count are a rejected sign-in, an unreachable warehouse, a warehouse timeout, a TLS failure, a schema change, a query error, and a removed data source. A failure inside Dashies never counts, and neither does one we could not classify. A manual or agent-triggered run never counts either, whatever it reports. You get one message, and only one: ```text Refresh suspended: arr-overview ``` ```text Dashies has stopped scheduling "arr-overview" after 6 failed refreshes in a row, which started on 2026-08-30 (UTC). Your warehouse rejected the connection sign-in. If the data source's 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. Anyone opening it still sees the data from 2026-08-29 (UTC). The one thing to do: fix the cause, then refresh it once. Use Refresh now on the Schedules page, or ask your AI tool to refresh it. A refresh that succeeds turns the schedule back on by itself. This is the only message about this suspension. Nothing else will refresh this dashboard until one refresh succeeds. ``` **Suspension ignores mute.** A muted dashboard that silently stopped refreshing forever is the worst outcome this feature has, so this one message is sent whatever the mute says. The category matrix is where an admin can switch it off; the stopping itself is not negotiable. ### What turns it back on Any of these, and the first is the one to reach for: - **A refresh that succeeds.** Use **Run now** on the Schedules page, or ask your AI tool to refresh it. The correcting action is the refresh. - **Resume schedule**, on the dashboard's row menu, on its schedule page, and on the [Issues page](/operate/monitor-refreshes). This clears the suspension without running anything, so use it after you have fixed the cause. - **Setting the schedule again** on any cadence other than manual. - **Republishing the dashboard**, which resets its refresh state anyway. ### Where a suspended dashboard shows - The **Schedules** table reads **Suspended** in the Data column, outranking Failing, and its **Next run** cell reads `None`. - The **Issues** page carries the count: `Suspended after 6 failures in a row, since 2026-09-05. Dashies stopped scheduling it, so nothing runs until it is resumed.` - Settings, then **Notifications** shows `Suspended schedules` with the number in that workspace, linking to the Issues page. - `get_refresh_status` from your AI tool reports it too. The Schedules table and the run permalink state the suspension without a count, deliberately: the streak that decides it is not readable from those surfaces, and the ordinary consecutive-failure count is a different number, because it also counts failures that never count toward suspension. ## 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. If the data source's 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. The dashboard still shows the data from its last successful refresh. Review the schedule and run history: https://acme.dashies.ai/app/schedules/d/8f3c1a2e-... 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 link lands on the dashboard, not on the list.** It carries the workspace in the host and the dashboard in the path, so one click opens the schedule and run history of the dashboard the email is about. **The two halves degrade independently**, which is worth knowing because the common case keeps the useful half. The HOST falls back to `https://dashies.ai` when the workspace cannot be resolved, and the app hands you on from there. The PATH falls back to the fleet page only when the row cannot name the dashboard, which is a different question. **An alert whose subject names a dashboard carries that dashboard's id**, which is every subject in the table above ending in ``. So an unresolvable workspace still leaves you with `https://dashies.ai/app/schedules/d/` and one click on the right dashboard. **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. 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 the 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. 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://acme.dashies.ai/app/schedules/d/8f3c1a2e-... 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. ## When the fault is ours A refresh that fails inside Dashies gets its own message rather than the failure email, because the failure email asks you to fix a warehouse that is working: ```text Refresh delayed on our side: arr-overview ``` ```text Our extraction service failed while refreshing "arr-overview". Your warehouse and your connection are fine. No action is needed from you. We retry on the next scheduled run, and we are looking at it. The run history on the Schedules page lists every attempt, so you can see for yourself when it starts working again. ``` These sit in the **Platform incidents** category, separately from your own failures, so switching our faults off never silences yours. ## 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 | |---|---| | 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://acme.dashies.ai/app/schedules/d/8f3c1a2e-... 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://acme.dashies.ai/app/schedules/d/8f3c1a2e-... 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. **Being overdue no longer depends on being emailed about it.** A muted dashboard that has fallen behind reads as late on the Issues page even though no message was sent, which is the one place it used to be invisible. ## The retry ladder This is how a failed **refresh** backs off. It is a different thing from how a failed **message** is retried, which is the next section. 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 | |---|---|---| | 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 | 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. ## If a message cannot be delivered Deciding to alert and sending the message are two separate steps. The decision is recorded the moment it is made, and the message is queued; a scheduled job sends it and records what came of it. A send that fails is retried on a widening ladder of its own: **5 minutes, 15 minutes, 1 hour, 3 hours, 6 hours, 12 hours**, up to six attempts. A refusal that cannot succeed on a retry, such as a rejected address, stops immediately rather than burning the ladder. Where the provider asks us to wait a specific time, we wait at least that long. This is why a mail outage no longer loses an alert. The message is still queued when the outage clears, and the run page shows every attempt. ## What never sends an 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. Suspension is the one exception and is sent anyway. - **A free plan.** No message 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. - **A category switched off** for the scope, or a channel switched off for you. ## 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.ai/app/schedules](https://dashies.ai/app/schedules). ### 2. Open the dashboard's row menu and choose Set schedule The item reads **Set schedule** on a dashboard that has none and **Edit schedule** on one that has. Either opens the dialog headed **Edit dashy**. ### 3. Turn the switch off 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 changes**, so you can close the dialog straight after. ### 4. Unmute from the switch, or from the list for that space The same switch unmutes. So does the **Muted dashboards** list, which lives where the dashboard's own space is administered: - **A workspace's dashboards**: Settings, then Notifications, under that workspace. Empty, it reads `No dashboard in this workspace is muted. Its author or any admin can mute one from the Edit dashy dialog on the Schedules page.` Each row carries an **Unmute** button. ::: :::note{title="Who can mute"} The switch is shown to the dashboard's author and to any admin of the workspace it lives in. It was once narrower than that, and a team dashboard was unmutable by anybody, including the person who published it. ::: Muting stops the failure messages. It does not stop the retries, it does not stop a suspension notice, 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 Edit dashy. ``` A dashboard with an open outage carries an amber bell instead: ```text Alerted you 2h ago. This dashboard has failed 3 times in a row and has not refreshed successfully since. ``` **Two sentences, and the split is the point.** The first is about a message and appears only when one actually landed; the second is about the dashboard and is true whether or not anybody was reached. A dashboard whose alert reached nobody still carries the bell, and says so without claiming an email. ## Check it worked 1. Open Settings, then Alerts. The threshold shows the value you picked, **My channels** shows email on, and any dashboards you muted are listed. 2. Confirm the alert address is not being filtered. Search your mail for `alerts@send.dashies.ai`. 3. As an admin, open Settings, then **Notifications**, and confirm each category reads the way you expect on both channels. 4. To confirm the delivery path end to end without breaking anything, connect Slack and use **Send test message**. It posts immediately and touches no dashboard. See [Slack alerts](/operate/slack-alerts). 5. On the Schedules page, a dashboard you have muted shows the struck-through bell on its row. Hover it to confirm the tooltip above.