Alerts & reports nothing triggered

[foreverls]

I have followed up with the instructions to set up superset email reports. but nothing is triggered. I have checked manually that email can be sent correctly. And worker can access the dashboard. superset worker and superset worker beat are also running. May I know how I can further troubleshooting for it? Thanks a lot!!

[dosubot[bot]]

Here are some key troubleshooting steps for Superset alerts and reports not triggering:

1. Make sure your superset_config.py includes the required CeleryConfig beat_schedule settings. You need to schedule the reports.scheduler task to run every minute and the reports.prune_log task daily at 00:10. Without this, scheduled alerts and reports won't run as expected. Example config:

class CeleryConfig:
    beat_schedule = {
        "reports.scheduler": {
            "task": "reports.scheduler",
            "schedule": crontab(minute="*", hour="*"),
        },
        "reports.prune_log": {
            "task": "reports.prune_log",
            "schedule": crontab(minute=10, hour=0),
        },
    }

See details here.

2. Double-check that the environment variable ALERT_REPORTS_NOTIFICATION_DRY_RUN is set to False in your worker container. If this is enabled (even if set to False in your config but True in the environment), reports will show as dispatched in logs but won't actually be delivered. This is a common pitfall—verify both your config and your container environment variables. More info here.

3. Check your Superset, Celery worker, and beat logs for any errors or skipped tasks related to alerts/reports. Sometimes issues are logged but not surfaced in the UI.

4. Review your alert/report configuration in the Superset UI—ensure the schedule, recipients, and status are set up correctly.

If these steps don’t resolve the issue, let me know what you find in the logs or config, and I can help dig deeper!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[foreverls]

@dosu step1 and step2 have already double checked. how to check celery worker and beat logs?

[dosubot[bot]]

You can check Celery worker and beat logs depending on how Superset is deployed:

• Docker: Use docker logs <container-name> for your worker and beat containers. All logs (INFO, WARNING, ERROR) are sent to stdout/stderr by default. This is the standard way to view logs in containerized setups.
• Kubernetes: Use kubectl logs <pod-name> for the relevant worker or beat pod. If you need more detail, set the SUPERSET_LOG_LEVEL environment variable to debug in your deployment config to increase verbosity [source].
• Manual/Local: If you start Celery with a command like celery --app=superset.tasks.celery_app:app worker ..., logs will appear in the terminal/session where you started the process [source].

If you want file-based logging, you can enable it in your Superset config with ENABLE_TIME_ROTATE = True and set FILENAME to your desired log path, but this is not the default for Celery processes [source].

Typical log messages to look for: scheduling/running reports, connection errors, screenshot failures, and notification delivery status. These logs are key for troubleshooting why alerts/reports aren't triggering [source].

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[foreverls]

@dosu logs from superset worker and superset worker beat, seems the report is running successful
worker: [2025-09-15 07:00:00,053: INFO/MainProcess] Task reports.scheduler[7c42c743-e91f-44af-9f55-c06dfaf06500] received
[2025-09-15 07:00:00,057: INFO/ForkPoolWorker-1] Task reports.scheduler[7c42c743-e91f-44af-9f55-c06dfaf06500] succeeded in 0.002714104950428009s: None
worker_beat: [2025-09-15 07:00:00,051: INFO/MainProcess] Scheduler: Sending due task reports.scheduler (reports.scheduler)

[dosubot[bot]]

The logs you shared show that the scheduler is running, but this only means the scheduling mechanism is working. For actual report delivery, you need to see logs for the reports.execute task—this is what runs the report, generates screenshots, and sends notifications. If you don’t see reports.execute in your worker logs after the scheduler runs, reports aren’t being processed.

Here’s what to check next:

• Look for reports.execute tasks and any related errors or warnings in your Celery worker logs.
• In the Superset UI or metadata database, check the ReportExecutionLog table for recent executions, their states, and any error messages—this often reveals silent failures that don’t show up in the UI.
• Make sure the EMAIL_REPORTS_USER (or the user configured for reports) can log in and access the dashboards/charts being reported. If this user lacks access, report execution will silently fail.
• If you use SSO or custom authentication, confirm that MACHINE_AUTH_PROVIDER_CLASS and WEBDRIVER_AUTH_FUNC are set up so background tasks can authenticate.
• If all else fails, review your report schedule configuration (recipients, schedule, status) and SMTP/notification settings again.

Silent failures are often caused by authentication issues, misconfigured dry-run mode, or notification errors that don’t show up as obvious failures in the logs. Checking the above should help pinpoint where things are getting stuck. For more details, see this discussion and this issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[foreverls]

@dosu how to setup MACHINE_AUTH_PROVIDER_CLASS and WEBDRIVER_AUTH_FUNC

[dosubot[bot]]

To set up MACHINE_AUTH_PROVIDER_CLASS and WEBDRIVER_AUTH_FUNC for Superset alerts/reports, add these options to your superset_config.py:

# Use the default machine auth provider (handles background login for screenshots/reports)
MACHINE_AUTH_PROVIDER_CLASS = "superset.utils.machine_auth.MachineAuthProvider"

# Optionally override the webdriver authentication function (for Selenium/Playwright)
WEBDRIVER_AUTH_FUNC = None  # Or set to a Python callable for custom auth logic

The default MachineAuthProvider logs in a user via Flask-Login and injects session cookies into the Selenium WebDriver session, so background tasks can access protected dashboards for screenshots and notifications. If you use SSO or custom authentication, you may need to implement your own provider class or authentication function and reference it here (e.g., "my_module.MySSOAuthProvider" or WEBDRIVER_AUTH_FUNC = my_custom_auth_func). Authentication is mandatory unless anonymous access is allowed in your Superset instance. For more details, see the config comments and usage patterns in the codebase [source], and background on how authentication works for automated screenshots [source].

If you need to support SSO, your custom class/function should handle login and inject the necessary cookies/session into the WebDriver. Let me know if you need a code example for a custom provider!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[foreverls]

@dosu I have setup for SCREENSHOT_SELENIUM_USER and SCREENSHOT_SELENIUM_USER_PASSWORD, do I still need to config for MACHINE_AUTH_PROVIDER_CLASS and WEBDRIVER_AUTH_FUNC?

[dosubot[bot]]

You do not need to configure MACHINE_AUTH_PROVIDER_CLASS or WEBDRIVER_AUTH_FUNC if you have set SCREENSHOT_SELENIUM_USER and SCREENSHOT_SELENIUM_USER_PASSWORD for standard username/password authentication. Superset's default MachineAuthProvider will use these credentials to log in and handle authentication for screenshots and reports automatically. Only set MACHINE_AUTH_PROVIDER_CLASS or WEBDRIVER_AUTH_FUNC if you have custom authentication needs like SSO or OAuth—otherwise, the defaults are sufficient for most setups (source).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[foreverls]

@dosu how to verify my SMTP setting is correct?