Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions docs-mintlify/admin/monitoring/alerts.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
---
title: Alerts
description: Get email notifications about API outages, database timeouts, and pre-aggregation build failures across your deployments.
---

Alerts send email notifications when a deployment has an API outage, a database
response timeout, or a pre-aggregation build fails or completes. Manage them from
**Alerts** in the account-level Admin panel.

<Note>

Available on the [Starter plan and above](https://cube.dev/pricing).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things on this callout.

Phrasingdocs-mintlify/CLAUDE.md fixes the wording for multi-tier availability: ✅ "Available on [Starter and above plans]". Every other page follows it (admin/monitoring/performance.mdx:13, admin/monitoring/usage-analytics.mdx:18, admin/account-billing/budgets.mdx:12 all use "Premium and above plans"). "the Starter plan and above" is a new variant.

Suggested change
Available on the [Starter plan and above](https://cube.dev/pricing).
Available on [Starter and above plans](https://cube.dev/pricing).

The claim itself — worth double-checking Starter is right. Every sibling page in this group is Premium+ or Enterprise (performance Premium+, usage-analytics Premium+, audit-log Enterprise, monitoring-integrations Enterprise add-on), so Starter would be the outlier here. If Alerts really is available on Free too, the callout should be dropped entirely rather than named at the lowest paid tier. Fix this →


</Note>

## Configuration

Click **New alert** and choose:

- **Event type** — one of the [event types](#event-types) below, or **All** to
match every type.
- **For deployments** — **All** deployments on the account, or specific ones.
- **Send alerts to** — **All users on this account** or **Specific users**; you
can also add **Custom email** addresses that aren't Cube Cloud users.

Existing alerts are listed in a table with their event type, deployments, and
recipients, and can be edited or deleted (individually or in bulk).

## Event types

| Event type | Triggered when |
| --- | --- |
| API outages | A deployment's API becomes unreachable. |
| Database response timeouts | A query to the connected data source times out. |
| Pre-aggregation build failures | A [pre-aggregation build](/admin/monitoring/pre-aggregations) fails. |
| Build completed | A deployment build finishes. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This row conflicts with the page intro. Line 7 says alerts fire when "a pre-aggregation build fails or completes", which reads as pre-aggregation build completion — but the table defines Build completed as "A deployment build finishes", a different thing entirely (deployment/model build vs. pre-agg build).

One of the two is wrong, and a reader picking event types can't tell which. If it's a deployment build, the intro sentence should say so:

Alerts send email notifications when a deployment has an API outage, a database response timeout, a pre-aggregation build fails, or a deployment build completes.

Also, the description frontmatter (line 3) lists only outages/timeouts/pre-agg failures and omits this fourth type. Fix this →


A pre-aggregation build failure notification links back to the pre-aggregation
and suggests [partitioning it][ref-partition-granularity] or configuring an
[export bucket][ref-export-bucket] if it's large.

[ref-partition-granularity]: /reference/data-modeling/pre-aggregations#partition_granularity
[ref-export-bucket]: /docs/pre-aggregations/using-pre-aggregations#export-bucket
1 change: 1 addition & 0 deletions docs-mintlify/docs.json
Original file line number Diff line number Diff line change
Expand Up @@ -370,6 +370,7 @@
"admin/monitoring/query-history",
"admin/monitoring/pre-aggregations",
"admin/monitoring/performance",
"admin/monitoring/alerts",
"admin/monitoring/audit-log",
"admin/monitoring/chats-history",
"admin/monitoring/query-history-export",
Expand Down
16 changes: 9 additions & 7 deletions docs-mintlify/embedding/iframe/dashboards.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -77,20 +77,22 @@ This works on both regular and published (embedded) dashboards. The filter is
only applied if a matching filter widget for that dimension already exists on the
dashboard.

## Allow CSV export
## Allow CSV, PNG, and PDF export

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renaming this heading changes the generated anchor from #allow-csv-export to #allow-csv-png-and-pdf-export, which breaks the existing in-repo link at docs-mintlify/embedding/iframe/events.mdx:214:

export](/embedding/iframe/dashboards#allow-csv-export)). The event fires when a

docs-mintlify/CLAUDE.md also says not to rename URL anchors — use Mintlify's explicit anchor syntax to keep inbound links working:

Suggested change
## Allow CSV, PNG, and PDF export
## Allow CSV, PNG, and PDF export {#allow-csv-export}

(The link text in events.mdx — "Dashboards → Allow CSV export" — should still be updated to match the new heading.) Fix this →


By default, embedded dashboards do not expose a download action on individual
widgets. To let viewers download a chart widget's data as a CSV file, add the
`allowExport=true` query parameter to the embed URL:
widgets. To let viewers download a chart widget as a CSV, PNG, or PDF file, add
the `allowExport=true` query parameter to the embed URL:

```text
https://your-tenant.cubecloud.dev/embed/dashboard/YOUR_DASHBOARD_PUBLIC_ID?session=YOUR_SESSION_ID&allowExport=true
```

When enabled, each chart widget's ⋮ menu shows a **Download as CSV** action. The
CSV is generated client-side from the data already loaded into the widget, so no
additional query is issued. The parameter is opt-in — omit it (the default) to
keep the download action hidden.
When enabled, each chart widget's ⋮ menu shows **Download as CSV**, **Download
as PNG**, and **Download as PDF** actions. The CSV is generated client-side from
the data already loaded into the widget, so no additional query is issued. The
PNG and PDF exports are rendered server-side and reflect the viewer's theme and
locale. The parameter is opt-in — omit it (the default) to keep the download
actions hidden.
Comment on lines +90 to +95

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PNG/PDF description here doesn't line up with the existing non-embedded description at docs-mintlify/docs/explore-analyze/dashboards/index.mdx:81-86, which says:

  • exports are server-rendered snapshots that can take up to a couple of minutes for large dashboards;
  • the filter and time-grain selections currently applied in the browser are carried into the export.

Neither of those (especially the latency, which matters a lot for an embedded viewer clicking a menu item) is mentioned here, while "reflect the viewer's theme and locale" appears in neither place. Two things worth confirming/tightening:

  1. Is the theme/locale claim actually backed by the CUB-4065 implementation? If it is, it'd be good in the canonical section too; if it's inferred, drop it.
  2. Rather than restating server-render mechanics (CLAUDE.md: "say it once"), consider a one-liner plus a link to the canonical section:
Suggested change
When enabled, each chart widget's ⋮ menu shows **Download as CSV**, **Download
as PNG**, and **Download as PDF** actions. The CSV is generated client-side from
the data already loaded into the widget, so no additional query is issued. The
PNG and PDF exports are rendered server-side and reflect the viewer's theme and
locale. The parameter is opt-in — omit it (the default) to keep the download
actions hidden.
When enabled, each chart widget's ⋮ menu shows **Download as CSV**, **Download
as PNG**, and **Download as PDF** actions. The CSV is generated client-side from
the data already loaded into the widget, so no additional query is issued. PNG
and PDF are [server-rendered snapshots](/docs/explore-analyze/dashboards#download-as-png-or-pdf)
and can take longer to produce. The parameter is opt-in — omit it (the default)
to keep the download actions hidden.

Also: does allowExport=true gate only the per-widget ⋮ menu, or does it also expose the whole-dashboard ⋯ → Download as PNG/PDF action described in that section? The current wording ("each chart widget's ⋮ menu") implies widget-only — worth stating explicitly either way, since that's the first question a reader will have.


## Show or hide the AI chat

Expand Down