When Apache Superset alerts and scheduled reports are worth building
Build scheduled reports and threshold alerts when people need dashboards and chart results pushed to them by email or Slack, rather than opened by hand, or when leaders need a notice the moment a metric crosses a line. Superset's architecture documentation describes alerts and reports as a feature that runs on a schedule and delivers content to recipients, and it depends on two components beyond the web application: the caching layer and Celery worker and beat processes. That dependency is the first decision. A team that only needs people to explore dashboards in the browser does not need Redis, workers or a scheduler, and every extra component is something your platform team must patch, monitor and back up.
The software itself carries no license cost. Apache Superset is released under the Apache License 2.0 (SPDX: Apache-2.0), and the project has no paid edition, so the cost of this feature is the infrastructure that runs it, the people who configure it and the time spent maintaining it. Ask whether the recipients, schedules and thresholds you need are stable enough to justify a worker tier that runs continuously. Also ask how many reports will run at the same time, because every scheduled delivery loads the warehouse and consumes worker capacity.
Before you commit, confirm three things with your own team: which databases the alerts will query and whether those queries are fast enough to run on a schedule, who owns each alert when its threshold or recipient changes, and whether your email relay and Slack workspace policies permit automated delivery from a self-hosted service. If the answers are unclear, a short pilot with two or three reports will show whether the effort is justified before you design the full rollout.
Which delivery options fit which reporting need
This table compares dashboard and chart reports, email and Slack delivery, scheduled reports and threshold alerts, and screenshot versus data attachments. Read each row as a question you must answer before rollout, since each choice changes what the worker renders, who receives it, and what can fail silently. The main takeaway is that screenshots and alerts depend on the caching layer and worker components, so every option needs that infrastructure in place first.
| Decision | When it fits | Operational trade-off |
|---|---|---|
| Dashboard report | Leadership or operations reviews that need a full page of related charts sent on one schedule | Renders the whole dashboard in a headless browser, so it takes longer and loads the warehouse once per chart |
| Chart report | A single metric that one audience tracks, such as daily order volume for one region | Smaller render and fewer warehouse queries, but several related charts need several schedules to manage |
| Scheduled report | Recurring summaries where the recipient needs the same view at a set time | Runs whether or not anything changed, so recipients can receive repeated content and inbox noise |
| Threshold alert | A condition that needs attention, such as a metric crossing a limit an owner has defined | Depends on the query returning the right value; a bad query or a dry-run setting can stop notifications without an error to the user |
| Email delivery | Broad audiences, external stakeholders, or recipients who do not use Slack | Needs working outbound SMTP and recipient addresses managed in Superset; confirm the mail relay allows the sender and image attachments |
| Slack delivery | Teams that act on alerts in a channel and need fast visibility | Requires a Slack app with the right scopes and channel membership; access follows the app, not each user's Superset role |
| Screenshot attachment | Reports where the rendered visual is the content and the reader needs no further interaction | Relies on the headless browser and the Playwright setup; rendering failures and font differences affect the image |
| Data attachment | Recipients who need the underlying rows to reconcile, filter or forward | Exposes query results outside the dashboard, so confirm row level security and export controls apply before sending |
How to set up reports and alerts in order
This sequence takes Superset from a working install to scheduled dashboard reports and threshold alerts that reach the right people. Each step ends with a check, so a failure is isolated to one component before the next one is added.
Confirm the metadata database and caching layer
Confirm that Superset's metadata database is PostgreSQL or MySQL within the versions the configuration documentation lists, not the SQLite default used by quickstart and PyPI installs. Then confirm that a Redis instance is reachable from the web and worker hosts, because the architecture documentation says alerts, reports and dashboard thumbnails depend on the caching layer and worker components. Check: superset can connect to the metadata database, and redis-cli ping returns PONG from each host that will run Superset processes.
Set the secret key and enable the feature flag
In superset_config.py, set a SECRET_KEY, since Superset will not start without one, and enable the alerts and reports feature flag under FEATURE_FLAGS. Confirm the exact flag name for your release in the configuration documentation before you change it. Restart the web server after the change. Check: the Alerts & Reports menu appears in the Superset UI for an admin user, and the web server log shows no configuration errors on startup.
Run Celery worker and beat on Redis
Point the Celery broker and results backend at the Redis instance, then start a Celery worker and a Celery beat process as separate services under your process manager or container orchestrator. Beat triggers scheduled reports and alert checks, and the worker executes them, so both must run. Check: the worker logs show it connected to the broker, beat logs show it started its schedule, and no task errors appear after a restart of either process.
Install the headless browser for screenshots
Reports that include charts or dashboards render them as images with a headless browser, which Superset drives through Playwright. Install the browser and its system libraries on every worker host, and make sure the worker's service account can launch it. Confirm the browser version against the Playwright and Superset versions in use, since the two are tied together. Check: a manual test run that renders one chart to an image completes on the worker host without a missing library or permission error.
Configure SMTP or the Slack app
Set up the delivery channels you plan to use. For email, add the SMTP host, port, sender address and authentication settings to the configuration, and confirm with your mail team that the worker host is allowed to relay through that server. For Slack, create a Slack app with permission to post to the target channels, then add its token to the configuration. Store credentials in your secrets system, not in the config file in plain text. Check: a test message sent from the worker host arrives in a test mailbox, and a test post appears in the Slack channel.
Create a test schedule with dry-run enabled
Create one report or alert for a small, low-risk dashboard or chart, with a recipient list limited to the project team. Before you save it, turn on the dry-run setting, which is controlled by ALERT_REPORTS_NOTIFICATION_DRY_RUN in the configuration documentation. Dry-run lets Superset run the job and log its result without delivering it, so a misconfigured channel does not send messages to users. Check: the schedule's execution log shows a run and a skipped delivery, which confirms the job reached the worker and the rendering step.
Verify delivery and turn dry-run off
Turn dry-run off in the configuration, restart the web server and worker so the change applies, then trigger the test schedule manually. Confirm the email or Slack message arrives with the expected image, title and link to the dashboard. Only after that succeeds, roll out production schedules to real recipients, and keep dry-run available for future changes to channels or credentials. Check: the test message arrives in each channel, the execution log records a successful delivery, and a second dry-run test is documented as the standard step before any future configuration change.
How Slack and email delivery differ in setup
Email delivery depends on an outbound mail path that Superset's Celery worker can reach. The worker builds the message and hands it to an SMTP relay, so the mail team controls most of what decides whether a report arrives. Superset itself mostly needs the relay host, port, transport security and a sender address that the relay accepts. Recipient rules matter just as much, because a schedule that sends to external addresses creates a data-sharing decision that goes beyond the platform.
- Relay access: The worker host must reach the SMTP relay on the agreed port, and the relay must accept mail from that host.
- Sender identity: The From address and any domain authentication records must match what the mail team has approved for automated messages.
- Recipient rules: Decide whether reports may go outside the company domain and who approves new recipients on a schedule.
- Attachments and size: Confirm whether the relay limits attachment size, since screenshot or CSV attachments can exceed that limit.
- Test path: Send a test message from the production worker, not from a laptop, so the network path is the one reports will use.
Before go-live, confirm the SMTP settings and any sender options in the Superset configuration documentation for your version, and check them against the mail team's relay policy.
Slack delivery is driven by a Slack app that Superset uses to post messages and files. The Slack workspace admin creates and approves the app, grants the scopes it needs and decides which channels it can join. Nothing is delivered until the app is installed in the workspace and invited to the target channel, so the most common failure is a schedule that runs without error while the bot posts nowhere. The platform team supplies the token to Superset as a secret and confirms which Slack features the installed Superset version uses.
- App approval: The workspace admin must approve or install the app, and many organizations restrict who can add apps at all.
- Scopes: Grant only the OAuth scopes the chosen Superset version documents for posting messages and uploading files.
- Channel membership: Invite the bot to each target channel, including private channels, because it cannot post where it is not a member.
- Token handling: Store the bot token as a secret and rotate it through the same process used for other integration credentials.
- Ownership: Name an owner for the app so that a token revocation or workspace policy change does not silently stop reports.
Before go-live, confirm the scopes, token type and any Slack-specific options against the Superset configuration documentation for your version, and confirm the Slack app settings with your workspace administrator in writing.
The two channels split the work across different teams, and the handoffs are where setup usually stalls. The Superset platform team owns the feature flag, the worker and beat processes, and the configuration keys. The mail team owns the relay and sender policy. The Slack workspace admin owns the app, its scopes and its channel access. Assigning each task to a named owner before installation avoids discovering a blocked relay or an uninstalled app during the first scheduled run.
- Platform team: Enables the alerts and reports feature, configures the delivery channel, and confirms the worker can reach the relay or Slack API.
- Mail team: Approves the sender address, the relay path and the rules for external recipients.
- Slack workspace admin: Approves the app, grants scopes and manages channel membership for the bot.
- Security or compliance reviewer: Reviews which datasets can reach which recipients, since a report exposes the same data its viewer sees.
- Application owners: Confirm which dashboards are scheduled and who receives them.
Before go-live, ask each owner to confirm their part in writing, and check the handoffs against the Superset configuration documentation for your version.
Why reports fail silently and how to catch it
Scheduled reports and alerts rarely fail with a loud error. They stop, skip or land in the wrong inbox, and the dashboard owner only notices when a stakeholder asks where the Monday report went. The cards below cover the failure modes we see most often, with the check that confirms each one.
Dry-run mode blocks delivery
When alert and report delivery runs in dry-run mode, Superset evaluates schedules and logs activity but does not send anything to email or Slack. Nothing in the user interface looks broken, so the schedule appears active while no messages leave the platform. Check the alert and report configuration for dry-run settings in every environment, then send a test delivery to a known internal address before you trust the schedule.
Beat process not running
Celery beat is the scheduler that decides when a report or alert should fire. If beat is down, restarting, or pointed at a different configuration than the web tier, schedules simply never trigger and no failure is recorded against them. Confirm that the beat process is running as its own service, check its logs for recent scheduling activity, and alert on its absence the same way you alert on the web tier.
Worker cannot reach the broker
Reports and alerts are queued through the caching layer and executed by Celery workers. A worker that cannot reach the Redis broker, or that reads a different broker URL from the web tier, accepts no tasks, and the queue grows without any user-facing error. Verify that the worker connects to the same broker as the web application, and watch queue depth so a growing backlog is visible before recipients notice.
Screenshot engine failing
Reports with dashboard or chart images depend on a headless browser run by the worker to render the screenshot. Missing browser binaries, missing fonts, memory limits in containers or blocked internal URLs can produce a report that arrives with no image or with a blank chart. Run a manual report with screenshots enabled on the worker image, open the delivered file, and confirm the chart is populated.
Recipients outside allowed domains
Email delivery depends on the SMTP relay accepting the sender and recipient domains, and many organizations restrict external recipients at the mail gateway. A report sent to a partner or a personal address can be rejected or quarantined while Superset records the attempt as sent. Test with an external address that your policy permits, and review mail gateway logs for rejected messages from the Superset sender.
Stale schedules after upgrades
Upgrades can change the metadata that backs schedules, and a schedule created under an earlier version may reference a chart, dashboard or database that moved, was renamed or was restored from an older backup. The upgrade guide asks you to back up the metadata database, run the migration commands, and test in staging first. After each upgrade, list active schedules and confirm each one still points at a valid object and produces a recent successful run.
Questions teams ask before building alerts and reports
How much does it cost to set up Superset alerts and scheduled reports?
The cost is mostly internal and partner engineering time, not licenses, because Apache Superset is Apache-2.0 licensed and has no paid edition. The work covers the Celery worker and beat processes, the Redis or other broker, the headless browser used for screenshots, the Slack app, and SMTP delivery. Setup is one-time work. Ongoing cost recurs through upgrade testing, worker capacity and report troubleshooting. Ask any quote to itemize each component, the environments included (staging and production), and whether testing of delivery is included.
How long does an alerts and reports setup take?
Duration depends mainly on how many delivery channels are needed, whether the network allows outbound mail and Slack traffic, how many existing workers and brokers you already run, and how many dashboards must be validated. A single email channel on an existing Celery stack is a much smaller job than a multi-environment rollout with Slack and screenshot rendering. Ask for a timeline tied to a written scope, with dependencies such as SMTP credentials and Slack app approval listed as client tasks.
What do we need to provide before the work starts?
Plan to provide:
- SMTP host, sender identity and credentials, or confirmation that a relay is allowed from the Superset network
- Slack workspace admin approval to install a custom app and the channels that will receive messages
- Outbound network egress from the worker and browser hosts to mail and Slack endpoints
- A named owner for each scheduled report and alert, plus a person who can approve changes
Without these, the build stalls at delivery testing, which is where most rollouts lose time.
Can our internal team set up alerts and reports without a partner?
Yes, if your team already runs Superset with Celery and Redis and has engineers comfortable with Python configuration, container images and mail or chat integrations. The feature depends on the feature flag, a worker and beat process, and a browser for screenshots, so the team needs to own all three. A partner usually adds value when the team lacks this combination, needs a tested runbook, or wants delivery verified across environments before users depend on it. Confirm your skills against the components listed in the architecture documentation.
Why does a scheduled report run but send nothing?
In most cases, dry-run mode is still enabled, so Superset logs the report as sent without delivering it. Check the alert and report configuration for dry-run behavior before debugging SMTP or Slack. Other common causes are a worker or beat process that is not running, a broker that is unreachable, or a screenshot step that fails because the headless browser cannot reach the Superset web address. Your runbook should check these in order and record the result of each test.
Should we plan for the Kubernetes operator when running reports on Kubernetes?
Yes, treat the operator as a planning factor, not a stable foundation. The Apache Superset Kubernetes Operator is in alpha, uses a v1alpha1 API, and its custom resource schemas may change between releases. The Helm chart is marked deprecated in current development documentation, so confirm which path your version uses before writing manifests. Budget extra review time for each Superset upgrade and pin operator versions in staging first.
What ongoing work do scheduled reports add after go-live?
Reports add recurring work because they depend on the worker, broker, browser and mail or chat services, all of which change over time. Each Superset upgrade needs a backup of the metadata database, staging tests and a review of breaking changes in UPDATING.md, as the upgrade documentation describes. Owners also need a process for retiring reports, rotating Slack and SMTP credentials and reviewing who can create alerts that send data outside your organization.
Do we need to set the feature flag and worker setup before building reports?
Yes. Reports and alerts are not usable until the feature flag is enabled and the Celery worker and beat processes run, with the caching layer in place as the architecture documentation requires. Decide the broker and results backend, the metadata database (PostgreSQL or MySQL in production) and the worker sizing before configuring delivery, because changing them later affects every schedule. Confirm the exact flag name and configuration keys against the version you deploy.
What upgrades and the Kubernetes path change for reporting
Every Superset upgrade can change how scheduled reports and alerts behave, so treat the reporting stack as part of the upgrade plan rather than an afterthought. Before you move versions, back up the metadata database, because the schedules, alert definitions and report logs live there. Then run superset db upgrade and superset init, and confirm that the Celery worker and beat processes restart on the new code. Read UPDATING.md for every version between your current and target release, since breaking changes to feature flags, configuration keys or the screenshot path can silently stop deliveries. Test the full reporting path in staging, including one real Slack post and one email, before production.
The Kubernetes path adds a decision that affects reporting directly. The Superset 6.1.0 documentation describes installs with the official Helm chart, but the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. The Operator is built with the Go Operator SDK, is in alpha, and exposes a v1alpha1 API whose custom resource schemas may change between releases. Ask your platform team whether the Operator can declare the worker and beat deployments, the Redis broker and the screenshot dependencies in the way your reporting design needs, and confirm the specific fields with the Kubernetes Operator documentation before you commit.
Plan for the operating consequences. An alpha API means you should pin the Operator version, review its changelog at each upgrade, and keep the custom resource manifests in version control so a schema change is a reviewed diff, not a surprise. Whichever path you choose, confirm which team owns worker scaling, beat restarts and Redis availability, because a stopped beat process produces no error in the dashboard. Ask any partner quoting this work to show how they will verify a scheduled report after each upgrade, and to name the owner of that check in the written scope.
How DeployOpen scopes and delivers Superset reporting
DeployOpen plans, builds, documents and supports self-hosted Apache Superset reporting inside your own infrastructure, including the feature flag, Celery worker and beat, screenshot rendering and Slack and email delivery. Each engagement starts from a written scope so your team knows what will be configured, tested and handed over before work begins.
How we scope
- We map which dashboards, charts and alerts need delivery, and who should receive each one.
- We confirm your metadata database, caching layer, broker and worker hosting, and outbound mail or Slack access.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We enable the reports feature flag, then configure Celery worker and beat processes with your broker and results backend.
- We set up Playwright screenshot rendering and test that dashboard images render on the worker hosts.
- We create the Slack app and email settings, then test sending from a non-dry-run configuration with recipients you approve.
How we hand over
- You receive configuration documentation covering flags, worker processes, scheduled jobs and secret locations.
- We provide a delivery test record showing each report and alert sent successfully, with the dry-run setting confirmed off.
- We walk your operators through monitoring worker health and checking delivery failures before handover closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We review reporting configuration when you upgrade Superset, using the upgrade guide and UPDATING.md notes.
- We can re-test delivery after changes to mail, Slack, worker hosts or the dashboards that feed reports.
