Apache Superset Alerts and Reports: A CFO-Grade Setup

Why CFOs and Ops Leaders Need Superset Alerts and Reports

Every finance leader has experienced the same problem: a critical KPI shifts, but nobody notices until the weekly board meeting. By then, the damage is done—or worse, the opportunity has passed. The traditional workaround is manual dashboards, email reminders, and spreadsheets. That approach doesn’t scale.

Apache Superset’s alerts and reports system solves this by automating the delivery of insights directly to the stakeholders who need them. When a metric breaches a threshold—say, cash burn exceeds your monthly budget by 15%—your CFO gets a Slack message or email instantly. When quarterly revenue targets need validation, a scheduled report lands in inboxes every Friday at 9 AM with the latest numbers, charts, and context.

Unlike Looker or Tableau, which bundle alerting into expensive enterprise tiers, Apache Superset provides native alerts and reports as part of the open-source platform. That means you control the infrastructure, own the data flow, and avoid per-seat licensing. For mid-market companies and scale-ups, this translates to significant cost savings—often 60–80% less than proprietary BI platforms—while maintaining CFO-grade reliability and customization.

This guide walks you through the full setup: from prerequisites and architecture to real-world configurations, best practices, and troubleshooting. By the end, you’ll have automated alerts firing when cash flow dips, scheduled reports delivering balance sheets to your board, and a system that scales as your data grows.

Understanding Superset Alerts vs. Reports: Core Concepts

Before diving into configuration, it’s critical to understand the distinction between alerts and reports in Apache Superset. They serve different purposes and require different setup approaches.

Alerts are event-triggered notifications. They fire when a condition is met—typically a SQL query result that breaches a threshold. For example: “If daily churn exceeds 5%, send a Slack message to the revenue ops team.” Alerts are reactive; they respond to data changes in real time (or on a schedule you define).

Reports are scheduled snapshots. They run on a fixed cadence—daily, weekly, monthly—and deliver a dashboard, chart, or PDF to a list of recipients via email or Slack. Reports are proactive; they ensure stakeholders have fresh data without asking for it. Think of a weekly cash flow report that lands in your CFO’s inbox every Friday morning, showing current burn rate, runway, and forecast.

Both rely on the same underlying infrastructure: Celery (a task queue), a message broker (Redis or RabbitMQ), a headless browser (Chromium or Playwright), and SMTP or Slack integration. The key difference is the trigger—threshold-based for alerts, time-based for reports.

For a CFO or ops leader, alerts are your early warning system. Reports are your dashboard—the regular cadence of truth that keeps stakeholders aligned.

Prerequisites: What You Need Before Starting

Setting up production-grade alerts and reports in Superset requires more than just the core platform. You’ll need to assemble a small stack of supporting infrastructure.

Core Requirements

Apache Superset 1.5 or later is essential. Earlier versions lack full alerting capabilities. If you’re running an older instance, upgrade before proceeding. D23 manages this for you, handling Superset updates, security patches, and infrastructure scaling, so you don’t have to.

Celery is the task scheduler that powers alerts and reports. It runs background jobs asynchronously, so your Superset instance doesn’t block while generating PDFs or sending emails. Celery requires a message broker—Redis or RabbitMQ. Redis is simpler for small deployments; RabbitMQ scales better for high-volume alerting.

A headless browser (Chromium or Playwright) is required to render dashboards and charts as PDFs or images for email delivery. This is non-negotiable for report generation. Without it, you can send alerts (which are text-based), but not visual reports.

SMTP configuration for email delivery, or a Slack workspace with bot token permissions for Slack integration. Most enterprises already have SMTP; Slack requires a workspace admin to create a bot and grant chat:write, files:write, and incoming-webhook permissions.

Feature flags enabled in your Superset configuration. By default, alerts and reports are disabled. You must explicitly enable them in your superset_config.py file.

Infrastructure Checklist

Before you start configuring, verify you have:

• Superset running on a stable deployment (Docker, Kubernetes, or bare metal)
• Redis or RabbitMQ accessible from your Superset instance
• Chromium or Playwright installed on the system running Celery workers
• SMTP credentials (server, port, username, password) or Slack bot token
• Database connectivity from Celery workers (they need to query your data sources)
• Adequate CPU and memory on Celery worker nodes (PDF generation is resource-intensive)
• Network access from Celery workers to external services (Slack API, SMTP servers)

If any of these are missing, alerts and reports will fail silently or with cryptic errors. The most common issue is Celery workers unable to reach the message broker or headless browser not installed.

Step 1: Enable Alerts and Reports Feature Flags

Alerts and reports are feature-flagged in Superset for a reason—they require careful configuration and can create operational overhead if not set up correctly. Enabling them is the first step.

Locate your Superset configuration file, typically superset_config.py or in environment variables if you’re using Docker. Add or update these feature flags:

FEATURE_FLAGS = {
    "ALERT_REPORTS": True,
    "DASHBOARD_NATIVE_FILTERS_SET": True,
    "ENABLE_TEMPLATE_PROCESSING": True,
}

The ALERT_REPORTS flag enables the alerts and reports UI and backend logic. The other two flags enable dashboard-level filtering and template variables, which are useful for dynamic reports (e.g., “send this report filtered by region”).

After updating the config, restart your Superset application. You should see a new “Alerts & Reports” menu item in the Settings section of the Superset UI (admin-only access).

If you don’t see the menu after restart, verify:

• The feature flag is spelled correctly (case-sensitive)
• You’ve restarted all Superset web server processes
• Your configuration file is being loaded (check logs)

Step 2: Configure Celery and the Message Broker

Celery is the engine that runs alerts and reports in the background. Without it, your Superset instance will try to generate PDFs synchronously, blocking requests and timing out.

In your superset_config.py, configure Celery:

CELERY_BROKER_URL = "redis://localhost:6379/0"
CELERY_RESULT_BACKEND = "redis://localhost:6379/0"
CELERY_DEFAULT_QUEUE = "superset"
CELERY_DEFAULT_EXCHANGE = "superset"
CELERY_DEFAULT_ROUTING_KEY = "superset.default"

If you’re using RabbitMQ instead:

CELERY_BROKER_URL = "amqp://guest:guest@localhost:5672//"
CELERY_RESULT_BACKEND = "db+postgresql://user:password@localhost/superset"

After configuring, start Celery workers on a separate machine or container:

celery -A superset.tasks worker --loglevel=info

Verify workers are running by checking logs for “Worker online” messages. If workers fail to start, the most common issues are:

• Redis/RabbitMQ not running or unreachable
• Python dependencies missing (install celery[redis] or celery[amqp])
• Database credentials in Superset config not accessible from worker nodes

Once workers are running, you’re ready to configure delivery channels.

Step 3: Set Up Email Delivery (SMTP)

Email is the most reliable delivery channel for reports. Most enterprises already have SMTP infrastructure, making this straightforward.

In your superset_config.py, configure SMTP:

SMTP_HOST = "smtp.gmail.com"  # or your corporate SMTP server
SMTP_STARTTLS = True
SMTP_SSL = False
SMTP_PORT = 587
SMTP_USER = "your-email@example.com"
SMTP_PASSWORD = "your-app-password"
SMTP_MAIL_FROM = "noreply@example.com"

For Gmail, use an app-specific password, not your regular password. For corporate SMTP, consult your IT team for credentials and settings.

After configuring, test SMTP by creating a simple alert or report and triggering it manually. Check your inbox and spam folder. If the email doesn’t arrive:

• Verify SMTP credentials are correct
• Check Superset logs for SMTP errors
• Ensure your firewall allows outbound SMTP traffic
• Confirm the SMTP_MAIL_FROM address is whitelisted by your email provider

Step 4: Integrate Slack for Real-Time Alerts

Slack integration is optional but highly recommended for alerts. Unlike email, Slack notifications are synchronous and visible to the whole team, making them ideal for urgent KPI breaches.

To set up Slack:

1. Create a Slack App: Go to api.slack.com/apps and create a new app in your workspace.
2. Grant Permissions: Under “OAuth & Permissions,” add these scopes: chat:write, files:write, and incoming-webhook.
3. Install to Workspace: Install the app and copy the Bot User OAuth Token (starts with xoxb-).
4. Configure Superset: In superset_config.py, add:

SLACK_API_TOKEN = "xoxb-your-token-here"

Alternatively, use Slack’s incoming webhooks for simpler setup (no scopes required). Generate a webhook URL in Slack and use it in your alert configuration.

After configuring, test by creating a test alert and selecting Slack as the delivery channel. If the message doesn’t appear:

• Verify the token has chat:write permission
• Ensure the bot is invited to the target channel
• Check Superset logs for Slack API errors
• Confirm the channel name is correct (use #channel-name format)

Step 5: Install and Configure the Headless Browser

Report generation requires a headless browser to render dashboards as PDFs or images. Superset supports Chromium (via Playwright) or Chrome.

Install Chromium:

On Ubuntu/Debian:

apt-get install chromium-browser

On macOS:

brew install chromium

On Docker (add to your Dockerfile):

RUN apt-get update && apt-get install -y chromium-browser

Configure Superset:

In superset_config.py:

REPORT_HEADLESS_BROWSER = "chromium"
REPORT_CHROMIUM_PATH = "/usr/bin/chromium-browser"  # adjust path as needed

To find the correct path, run which chromium-browser on your system.

After installing, test by generating a report manually. If the PDF doesn’t generate:

• Verify Chromium is installed and the path is correct
• Check Celery worker logs for browser errors
• Ensure Celery workers have permission to execute Chromium
• Confirm adequate disk space and memory on worker nodes

Step 6: Create Your First Alert (Threshold-Based)

Now that infrastructure is in place, let’s create a real alert. Imagine you’re a CFO and want to be notified when daily revenue drops below $50,000.

In the Superset UI:

1. Navigate to Alerts & Reports: Go to Settings → Alerts & Reports.
2. Create Alert: Click ”+ Alert” or “New Alert.”
3. Select Dashboard or Chart: Choose the dashboard or chart that contains your revenue metric. For this example, select your revenue dashboard.
4. Define the Condition: This is the SQL query or metric that triggers the alert. In Superset, you typically select a chart and set a threshold. The condition might be:
   • Chart: “Daily Revenue”
   • Condition: “Value is less than 50000”
5. Set Frequency: Choose how often the alert checks the condition. Options include:
   • Every minute (not recommended; creates noise)
   • Every 5 minutes
   • Every hour
   • Every day at a specific time
6. Configure Delivery: Select Slack or email, and specify the channel or recipient list.
7. Add Context: Write a message that explains what the alert means and what action to take. Example: “Daily revenue has fallen below $50K. Check sales pipeline and customer churn immediately.”
8. Save: Click Save and test the alert.

Apache Superset’s official documentation on alerts provides detailed UI guidance. For more advanced configurations, the dbt blog has a comprehensive guide to CFO-grade dashboard alerts, including SQL-based conditions and best practices.

Step 7: Set Up Scheduled Reports (Time-Based)

Unlike alerts, reports are time-based and deliver snapshots of dashboards or charts on a fixed schedule. Let’s set up a weekly cash flow report for your CFO.

In the Superset UI:

1. Navigate to Alerts & Reports: Go to Settings → Alerts & Reports.
2. Create Report: Click ”+ Report” or “New Report.”
3. Select Dashboard: Choose the cash flow dashboard.
4. Name the Report: “Weekly Cash Flow Summary.”
5. Set Schedule: Choose weekly, and specify the day and time (e.g., Friday at 8 AM).
6. Configure Delivery: Select email and add recipients (CFO, controller, finance team).
7. Choose Format: Superset can send dashboards as:
   • Embedded images in the email body
   • PDF attachment
   • Link to the dashboard in Superset
8. Add Custom Message: Include context, like “This report shows current cash position, burn rate, and runway forecast. Contact Finance with questions.”
9. Save and Test: Save the report and manually trigger it to verify email delivery.

Preset’s documentation on Alerts & Reports covers similar workflows and is useful for understanding how managed Superset handles these features.

Step 8: Advanced Configuration—SQL-Based Alerts

For more sophisticated scenarios, you can define alerts using raw SQL queries instead of chart thresholds. This is especially useful for finance teams that need to monitor derived metrics or multi-table conditions.

Example: Alert when accounts receivable aging exceeds 60 days for more than 20% of outstanding invoices.

In Superset’s alert configuration, select “SQL Query” as the condition type and enter:

SELECT CASE
  WHEN (SELECT COUNT(*) FROM invoices WHERE days_outstanding > 60) / 
       (SELECT COUNT(*) FROM invoices WHERE status = 'outstanding') > 0.20
  THEN 1
  ELSE 0
END AS alert_triggered

When this query returns 1, the alert fires. This approach is powerful because it lets you define any condition using your data warehouse’s SQL dialect.

The Apache Superset GitHub discussions confirm support for SQL-based alerts, and the community has shared numerous examples.

Step 9: Monitoring and Troubleshooting

Once alerts and reports are live, you need visibility into their execution. Superset logs all alert and report activity, but you need to know where to look.

Check Celery Logs: Celery workers log every task they execute. If an alert fails to send, the error will be in the Celery logs. Look for:

ERROR: Failed to send alert 'Daily Revenue' via Slack
ERROR: SMTP connection failed
ERROR: Chromium timeout while rendering PDF

Monitor Celery Queue Depth: If alerts are piling up in the queue without executing, your Celery workers may be overloaded or crashed. Check the queue:

celery -A superset.tasks inspect active

If the queue is growing but no tasks are executing, restart your Celery workers.

Test Alerts Manually: In the Superset UI, every alert and report has a “Test” or “Send Now” button. Use this to verify delivery without waiting for the scheduled time.

Set Up Alerting on Alerts: Meta, but important—monitor your Celery infrastructure itself. If Redis goes down, your alerts will fail silently. Set up monitoring on:

• Redis/RabbitMQ availability
• Celery worker health
• SMTP/Slack API availability
• Disk space on worker nodes (PDF generation is disk-intensive)

A practical tutorial on automated alerts and reporting walks through common setup issues and solutions.

Step 10: Scaling Alerts and Reports for Enterprise

As your organization grows, the volume of alerts and reports will increase. A single Celery worker can handle ~100 alerts and reports per day, but beyond that, you’ll need to scale.

Horizontal Scaling: Add more Celery worker nodes. Each worker processes tasks independently, so adding workers linearly increases throughput. For a company with 500+ stakeholders and 50+ daily reports, you’ll want 5–10 workers.

Separate Worker Pools: Dedicate specific workers to report generation (which is resource-intensive) and alert execution (which is lighter). In your Celery configuration:

celery -A superset.tasks worker -Q reports --loglevel=info
celery -A superset.tasks worker -Q alerts --loglevel=info

Database Optimization: Alerts and reports query your data warehouse frequently. Ensure your database can handle the load. For large dashboards, consider:

• Materializing views for frequently-used metrics
• Adding indexes on columns used in alert conditions
• Scheduling reports during off-peak hours

Caching: Superset caches query results. For alerts, disable caching to ensure fresh data:

CACHE_QUERY_BY_DEFAULT = False

For reports, you can enable caching if your stakeholders accept slightly stale data (e.g., 1-hour-old).

Best Practices for CFO-Grade Alerts and Reports

Setting up alerts and reports is one thing; maintaining them as a reliable system for finance leadership is another. Here are practices that separate amateur deployments from enterprise-grade ones.

1. Define Clear Ownership: Assign one person (typically a data analyst or BI engineer) to own alerts and reports. They should review every new alert, test it before going live, and monitor execution. Without clear ownership, alerts become noise and reports become stale.

2. Establish Naming Conventions: Name alerts and reports consistently. Examples:

• [CRITICAL] Daily Revenue < $50K
• [Weekly] Cash Flow Summary
• [Monthly] Board Metrics Pack

The prefix indicates urgency and frequency. This makes it easy to scan the alerts list and understand what’s running.

3. Set Appropriate Thresholds: Avoid alert fatigue. If your CFO gets 10 alerts per day, they’ll ignore all of them. Set thresholds conservatively. For example:

• Alert on revenue drops > 20%, not > 5%
• Alert on cash runway < 3 months, not < 6 months
• Alert on customer churn > 10%, not > 5%

4. Document Alert Logic: For each alert, document why the threshold exists and what action the recipient should take. Store this in a shared wiki or Notion doc. Example:

Alert: Daily Revenue < $50K
Owner: CFO
Threshold: $50K (20% below 90-day average)
Action: Check sales pipeline, contact VP Sales
Frequency: Daily at 9 AM
History: Created Q3 2024, threshold adjusted Q4 2024

5. Schedule Reports During Off-Peak Hours: Report generation is CPU and memory intensive. Schedule reports during nights or weekends to avoid impacting user queries. If your CFO needs Friday morning reports, generate them Thursday night.

6. Use Distribution Lists: Instead of adding individual email addresses to reports, use distribution lists (e.g., finance-team@company.com). This makes it easy to add or remove recipients without updating Superset.

7. Include Context in Emails: A dashboard PDF is useless without context. Always include a message that explains:

• What the report shows
• Key metrics to focus on
• Comparison to previous period (e.g., “Revenue up 15% vs. last week”)
• Action items or questions to investigate

8. Version Control Your Dashboards: Before creating a report from a dashboard, commit the dashboard definition to version control (e.g., Git). This lets you track changes and revert if needed. D23 supports dashboard versioning and export as part of its managed Superset offering.

9. Test Before Going Live: Always manually test an alert or report before scheduling it. Use the “Test” button in the UI. Verify:

• The email arrives in the correct inbox
• The Slack message appears in the right channel
• The data is accurate and current
• The formatting is readable

10. Monitor False Positives: Some alerts will fire due to data anomalies, not real issues. Track false positive rate. If an alert triggers more than once per month without actionable insights, revisit the threshold.

Real-World Example: Finance Operations Setup

Let’s walk through a complete setup for a mid-market SaaS company with $10M ARR, 50 employees, and a 3-person finance team.

Goals:

• Alert CFO immediately if daily revenue drops below $30K
• Alert controller if accounts payable aging exceeds 45 days
• Send weekly cash flow report to finance team every Friday at 8 AM
• Send monthly board metrics pack to CEO and board every month on the 1st

Setup:

1. Infrastructure: Deploy Superset on Kubernetes with 2 Celery workers (one for reports, one for alerts), Redis for the message broker, and Chromium on worker nodes.

2. Alerts:

   • Alert 1: “Daily Revenue < $30K” → Slack #finance-alerts, Slack #ceo
   • Alert 2: “AP Aging > 45 days” → Email to controller, Slack #finance-alerts
   • Frequency: Every hour for alert 1, every day at 5 AM for alert 2

3. Reports:

   • Report 1: “Weekly Cash Flow” → Email to finance-team@company.com, Friday 8 AM
   • Report 2: “Monthly Board Metrics” → Email to ceo@company.com, board@company.com, 1st of month at 6 AM

4. Monitoring: Set up CloudWatch (or equivalent) alerts on Celery queue depth and worker health. If queue depth exceeds 50 tasks, page the on-call engineer.

5. Maintenance: Weekly review of alert execution logs. Monthly review of alert thresholds with CFO. Quarterly review of report recipients and content.

This setup takes ~40 hours to implement (infrastructure, configuration, testing, documentation) and costs ~$2K/month in cloud infrastructure. A comparable Looker or Tableau deployment would cost $15K–30K/month in licensing alone, plus 80+ hours of implementation.

Comparing Superset Alerts to Competitors

How does Superset stack up against Looker, Tableau, Power BI, and Metabase for alerts and reports?

Looker: Looker’s alerting is powerful but expensive. Alerts require a Looker license ($70/user/month), and you’re locked into Looker’s infrastructure. Superset is open-source and self-hosted, so you own the data flow.

Tableau: Tableau’s data-driven alerts are solid, but they’re bundled into the Tableau Cloud platform ($70/user/month). Like Looker, you’re paying per user. With Superset, you pay for infrastructure, not seats.

Power BI: Power BI alerts are basic—email-only, limited customization. Superset supports Slack, email, and custom webhooks. Power BI also requires Microsoft licensing ($10–20/user/month), which adds up.

Metabase: Metabase offers free alerts, but they’re limited to email and basic thresholds. Superset’s alerts are more sophisticated, supporting SQL conditions, multiple delivery channels, and complex logic.

Preset: Preset is a managed Superset offering that handles infrastructure for you. Alerts and reports work identically to self-hosted Superset. Preset is a good middle ground if you don’t want to manage Celery, Redis, and Chromium yourself. D23 also offers managed Superset, with additional features like AI-powered text-to-SQL and MCP integration for programmatic data access.

For finance teams that need reliability, customization, and cost control, Superset is the clear winner.

Common Pitfalls and How to Avoid Them

Pitfall 1: Celery Workers Crash Silently: Workers fail because Redis is down, database is unreachable, or Chromium is missing. Solution: Monitor worker health continuously. Set up automated restarts (systemd, Kubernetes, etc.). Test the full stack weekly.

Pitfall 2: Alert Fatigue: Too many alerts, all going to the same Slack channel, leads to alert blindness. Solution: Limit alerts to truly critical metrics. Use separate channels for different severity levels (#finance-critical vs. #finance-info). Document why each alert exists.

Pitfall 3: Stale Data in Reports: Reports are generated from cached query results, leading to reports that are hours old. Solution: Disable query caching for alerts and reports. Accept that reports will be slightly delayed (1–5 minutes) in exchange for fresh data.

Pitfall 4: PDF Generation Timeouts: Large dashboards take 30+ seconds to render as PDFs, causing Celery tasks to timeout. Solution: Increase Celery timeout settings. Break large dashboards into smaller reports. Schedule PDF generation during off-peak hours.

Pitfall 5: Missing Email Attachments: Slack messages work, but email attachments fail silently. Solution: Test email delivery with attachments before going live. Verify SMTP supports MIME attachments. Check email provider’s size limits (Gmail: 25MB, Outlook: 20MB).

Pitfall 6: Recipient Overload: Reports go to 50+ people, most of whom don’t need them. Solution: Use distribution lists and periodically audit recipients. Ask recipients if they actually read the report. Consolidate reports when possible.

Conclusion: Building Your Finance Intelligence System

Apache Superset’s alerts and reports system is a powerful tool for finance leaders who want real-time visibility into their business without the cost and complexity of Looker or Tableau. By following this guide—from infrastructure setup through best practices—you’ll build a reliable, scalable system that delivers insights to the right people at the right time.

The key is starting simple: one critical alert, one weekly report. Test thoroughly. Once you’re confident, expand. Add more alerts, more reports, more stakeholders. Scale your Celery workers as volume grows. Monitor continuously.

If managing Superset infrastructure feels like a distraction from your core business, D23 offers fully managed Apache Superset with alerts and reports pre-configured, along with AI-powered analytics and expert data consulting. Whether you self-host or use a managed service, the principles in this guide remain the same: clear ownership, appropriate thresholds, fresh data, and reliable delivery.

Your CFO shouldn’t have to ask for the cash flow report—it should land in their inbox every Friday morning. Your ops team shouldn’t discover a KPI breach in a meeting—they should get a Slack alert the moment it happens. That’s CFO-grade analytics, and it’s achievable with Superset.