Alerts, channels and retries

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:

Dashies <alerts@send.dashies.ai>

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

The two query-host subjects name the workspace whose host it is, where that name was carried, as Query host not answering: <workspace>. 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 <date> 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: <slug>, 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.

It refreshes from the team's "Analytics prod" data source.

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.

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:

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 <date> 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:

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:

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.

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:

Refresh suspended: arr-overview

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

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 <slug>. So an unresolvable workspace still leaves you with https://dashies.ai/app/schedules/d/<dashboard-id> 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:

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:

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:

Refresh delayed on our side: arr-overview

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:

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

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.

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.

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.

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.

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

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 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:

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:

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