GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Cube Documentation home page
  • Demos
  • Changelog
  • Community
  • Get Started
  • Documentation
  • Admin
  • Embedding
  • Reference
  • Cube Core
  • Recipes
  • API
  • Connecting to multiple data sources
  • Querying concurrency

This view

  • Original page
  • New address

GeezerVison is showing docs.cube.dev — Alerts - Cube Documentation

Alerts notify you by email when something happens in your account: an API goes down, a database stops responding in time, a pre-aggregation build fails, or a build finishes.
Available on Premium and above plans.

​
Manage alerts

Click Alerts in the sidebar to see every alert configured on the account. Click Create alert to add one, or use the edit and delete icons on a row to change or remove an existing alert. On plans below Enterprise, only account administrators can manage alerts. On the Enterprise plan, access also follows the AlertsCreate, AlertsRead, AlertsUpdate, and AlertsDelete actions. Administrators always have access, and the built-in Developer and AIBI Developer roles carry all four. The same four actions also govern budgets.
These four actions are not among the ones you can pick when you build a custom role. To grant them, assign a built-in Developer or AIBI Developer role.

​
Event types

Each alert watches a single event type:
Event typeWhat it detectsResolved email
API outagesThe API stops respondingYes
Database response timeoutsThe database takes too long to answerYes
Pre-aggregation build failuresA pre-aggregation build failsYes
Build completedA build reaches a terminal stateNo
AllEvery event type abovePer event type
The first three are conditions: Cube emails you when the condition starts, then emails you again with a Resolved — subject prefix when it clears. While a condition persists, Cube does not re-send the same alert for a while — 1 hour for API outages and database response timeouts, 3 hours for pre-aggregation build failures.
Build completed fires when a build finishes, whether it succeeded or failed. The subject line reads Build finished with status: <status>. It is a point-in-time event, so it has no resolved email.

​
Deployments

An alert applies either to All deployments in the account, or to a Specific set you pick. Choosing Specific requires at least one deployment.

​
Recipients

Under Send alerts to, pick who receives the alert:
  • All users on this account — every user receives it. Use the Also send to field to add email addresses of people outside the account.
  • Specific users — use the Recipients field to search for users on the account, or type any email address. Add at least one recipient, a user or an address.
If you type the email address of a user on the account, Cube adds that user instead, so nobody receives the same alert twice.
All users on this account only reaches users who have signed in at least once. Users who were invited but never signed in do not receive alerts.

​
Delivery

Alerts are delivered by email — there is no Slack, webhook, or PagerDuty delivery. Scheduled refresh notifications, which cover dashboard refresh outcomes, are a separate feature with its own delivery channels. Recipients who are Cube users also get each alert, and its resolution, in their inbox. To alert from your own observability stack instead, export telemetry with monitoring integrations.
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.