Why Superset reports need a Playwright plan before 7.0.0
If your Superset deployment sends scheduled alerts, reports or dashboard thumbnails, those messages depend on screenshots, and from 7.0.0 every report screenshot is taken only by Playwright driving headless Chromium. Selenium, Firefox and the WEBDRIVER_TYPE setting are not supported in that release, so a configuration that works today will not carry forward unchanged. The 7.0.0 release candidate, 7.0.0rc2, was listed on the GitHub releases page on October 16, 2026. That is a pre-release, so confirm the final 7.0.0 date on the apache/superset releases page before you set a cutover date, and do not assume the candidate's behavior is final.
Until you move to 7.0.0, the supported path is still the 6.x line. Superset 6.0.0 added tiled Playwright screenshots, enabled by default, for dashboards with 20 or more charts or dashboards taller than 5000 px. That change means a large dashboard may already produce a different image set than your Selenium-era reports, so the first comparison should be run on 6.x in staging, not after an upgrade. Check the UPDATING.md notes for the exact tiling behavior and any settings that control it, and list which of your scheduled reports cross those thresholds.
Treat this as a planned migration, not a configuration tweak. The change touches the browser runtime in your worker image, Chromium availability in the container, the screenshot dimensions and layout that recipients see, and the alert and report test runs your team relies on. Ask your platform owner which worker images bundle Chromium, confirm how your Celery workers reach the web server during screenshot capture, and inventory every report and thumbnail that is currently in use. Schedule the staging test, the image rebuild and the production cutover as separate steps with a rollback point between them.
What changes in report and thumbnail screenshots
This table compares how report and thumbnail screenshots behave before and after the move to Playwright. Read each row as a change to check in your own deployment, with the action that closes it. The main takeaway is that the driver switch is only part of the work: tiled output for large dashboards, image differences for recipients, and the caching and worker stack all need testing before Selenium support goes away.
| Change | Impact | Action needed |
|---|---|---|
| Playwright with headless Chromium is the only screenshot driver from 7.0.0 | Report screenshots are taken only by Playwright driving headless Chromium in Superset 7.0.0 and later | Confirm the Chromium build runs on your workers and that the image or host has the libraries it needs |
| Selenium, Firefox and WEBDRIVER_TYPE are no longer supported | Existing configuration that sets WEBDRIVER_TYPE or relies on Firefox will not produce screenshots after the upgrade | Search your configuration and custom code for WEBDRIVER_TYPE and Firefox references, then remove or replace them |
| Tiled Playwright screenshots added in 6.0.0 | Tiling is on by default for dashboards with 20 or more charts or taller than 5000 px, so output for large dashboards can change shape | Review your largest dashboards in staging and decide whether the tiled output suits recipients |
| Image output differences | Rendering may differ from earlier Selenium captures in fonts, spacing, sizing and page layout, which recipients may notice | Compare sample reports from before and after the change with the people who receive them and agree on acceptable differences |
| Caching layer and Celery workers | Alerts, reports, async queries and dashboard thumbnails depend on the caching layer and worker components, so a gap there stops screenshot delivery | Confirm Redis or your chosen cache and the Celery worker and beat processes are running and monitored in the target environment |
How tiled screenshots change output for large dashboards
Dashboards with fewer than 20 charts that are not taller than 5000 px fall below both tiling thresholds, so the default output is a single screenshot of the whole dashboard. Recipients should see one image close to what Selenium produced, but the renderer is now headless Chromium, so fonts, spacing and chart timing can differ.
- Single image output: the attachment or inline image should cover the full dashboard as one file, with no tile seams.
- Font and layout drift: compare text wrapping, legend placement and axis labels against a Selenium-generated sample of the same dashboard.
- Chart load timing: confirm every chart has finished rendering before capture, since slow queries can leave empty panels.
- Height margin: measure the image height against the 5000 px threshold, because a small layout change can push a dashboard across the line.
Send a test report to a sample recipient list and open it in the mail clients your readers use. Confirm the image stays legible at the size those clients display it.
From Superset 6.0.0, dashboards with 20 or more charts, or dashboards taller than 5000 px, are tiled by default. Superset splits the capture into several Playwright screenshots, so recipients may receive a set of images where earlier reports carried one file. Confirm the delivery format in the alerts and reports documentation for your release before you write recipient guidance.
- Tile boundaries: a chart that crosses a tile edge can be cut in two, so review the seams on the largest dashboards in the test send.
- Tile order: confirm that tiles arrive in reading order and that recipients can tell which tile comes first.
- Message size: several images add to the attachment total, so check the result against the mail limits your organization enforces.
- Context per tile: check whether each tile is clearly tied to the same dashboard, using the report title and subject line as the anchor.
- Version check: confirm the tiling default for your release in the upgrade notes and confirm your instance runs 6.0.0 or later.
Run the test send on the tallest and widest dashboards first, since they show tiling behavior most clearly. Record the number of tiles and the seam review results so the team can repeat the check after each upgrade.
Some teams want one image per dashboard, usually for archives or for recipients whose systems handle a single attachment well. Whether that is possible depends on the tiling options in your release, so check the current options in the configuration documentation before you promise it to readers. If no option fits your version, the practical route is a layout decision made with the dashboard owners.
- Confirm the setting: find the tiling option for your version in the configuration documentation and test it on a staging copy before changing production.
- Layout reduction: fewer charts or a shorter layout can keep a dashboard under both thresholds, but readers will see less on each report.
- Readability at scale: a very tall single image may be scaled down by viewers, which can make small text unreadable.
- Downstream consumers: check any archive job or parser that expects one file per report before changing the output.
- Split reports: some dashboards may need a summary report and a detail report instead of one long capture.
Before changing any layout, test the tallest dashboards with the readers who depend on them and confirm the result in your staging environment.
How to test report output before the cutover
Test report output on a staging copy of the metadata database, connected to a worker pool sized and configured like production, so that alert, report and thumbnail behavior reflects what users will actually receive. Choose a fixed set of dashboards before testing starts and keep it unchanged through the cutover. Include a small dashboard, a large one that will trigger tiled screenshots, a tall layout, a dashboard with filters applied through the report's saved state, one that uses native filters, and one that uses cross-filters. Render each one with the current Selenium setup first and keep those images as the baseline. Then run the same schedules on Playwright and compare the outputs side by side, checking fonts, legends, axis labels, colors, page breaks in tiled captures and whether any chart is blank or still loading when the screenshot is taken.
Measure what the change does to the worker, not only to the picture. Record how long each report takes to render and send on both engines, and watch worker memory and Chromium process counts across a full run of the schedule, including the large dashboards. Confirm the worker concurrency and timeouts you configure in production still hold under that load. Verify recipients by sending to test mailboxes and, where you use Slack or other channels, to test destinations, and confirm the attachments open and match the expected format. Then force failures on purpose, for example by pointing a report at a dashboard the test user cannot see or by stopping the browser process, and confirm that the failure produces the alert your on-call team expects, in the channel and with the detail they need. Ask your team to document the expected alert text before the test so the result can be checked against it.
What to inventory and back up before switching screenshot drivers
Changing the screenshot driver touches more than one setting. The reports, thumbnails and container image all depend on each other, so the work before the switch decides how easily you can roll back. Start with the data you cannot recreate, then the configuration and the runtime that will render the screenshots.
Back up the metadata database
Take a full backup of the metadata database before any upgrade step, because alert and report schedules, dashboards and users all live there. Follow the backup and migration sequence in the upgrade documentation, then confirm the backup restores into a scratch database. Record the Superset version and the database version alongside the backup so you know what it can be restored into. Keep this backup until the new release has run reports for a full cycle.
Inventory every report schedule
List each alert and report schedule with its owner, the dashboard or chart it screenshots, its recipients and its delivery channel. Note which schedules run on dashboards with many charts, since those are the ones most affected by tiled screenshots. Mark schedules that nobody has opened in a long time so you can retire them instead of testing them. Use this list as the acceptance checklist for the staging test.
Record current screenshot settings
Capture every setting that controls how screenshots are taken today, including any WEBDRIVER_TYPE value, custom WebDriver options, browser binary paths and screenshot timeouts in your configuration file. Mark each one as keep, change or retire. Settings tied to Selenium or Firefox will not carry over to Playwright and should be removed, not translated. Store the configuration in version control so the before and after states can be compared.
Confirm the Chromium runtime
Decide which container image or host will run Chromium and Playwright, and confirm the Chromium-related image changes for your target release before building. Check whether your current image is a custom build, because a build that depends on a Chromium package from an older base may need rework. Confirm that the worker can reach the web server for rendering and that the browser has the fonts your dashboards use. Test the image in isolation before it touches reports.
Build a staging environment
Staging must mirror production with the caching layer and Celery workers enabled, because alerts, reports and thumbnails depend on both. Use a copy of the production metadata database, with recipient addresses redirected so test reports do not reach real users. Include representative dashboards, especially large ones and the ones that fail today. Confirm that the workers run the new image before you schedule the test.
Plan the version path to 7.0.0
Map the route from your current release through 6.x to 7.0.0, and read the breaking change notes for every version you will pass through. The 7.0.0 line is a pre-release at the time of writing, so confirm its final release status before you commit a production date. Record which changes affect your dashboards, databases and custom plugins, and sequence the upgrades so each stage can be tested and rolled back. Ask your team whether the path needs an intermediate release.
How to move reports from Selenium to Playwright in order
This sequence takes a running Superset deployment from Selenium-based report screenshots to Playwright and headless Chromium, with a tested rollback point at every stage before the switch in production.
Back up the metadata database
Before anything changes, the platform owner takes a full backup of the metadata database and confirms it can be restored to a separate instance. Record the Superset version, the image tag, and the current WEBDRIVER_TYPE and screenshot settings so the previous state can be rebuilt exactly. This backup and the previous image together form the rollback point for every later step. The step is done when a test restore completes and someone other than the author has checked the restored row counts for alerts, reports and dashboards.
Upgrade a staging copy along the supported path
The platform team restores the backup into a staging environment and upgrades Superset there, following the supported upgrade path rather than jumping straight to the newest release. Read UPDATING.md for every release between the current version and the target, and note each breaking change that touches reports, alerts, thumbnails, the Docker image or Chromium. Confirm the target release is one that supports Playwright-only screenshots before relying on it. The step is done when the staging upgrade completes with no failed migrations and the upgrade notes have been reviewed and signed off by the team that owns reporting.
Install and verify Chromium and Playwright in the worker image
Report screenshots run in the Celery worker, so the worker image must contain a working Chromium and the Playwright dependencies that the target release expects. Build the image from the same base your organization uses for other Superset images, and confirm that Chromium launches headless as the worker user with the same file system and memory limits used in production. Check that the worker can reach the Superset web endpoint it uses to render pages, including any proxy or internal DNS path. The step is done when a manual screenshot task run from the worker produces a valid image, and the image digest is recorded next to the previous one.
Run the report test matrix and record differences
Build a test matrix that covers each report type you run in production: dashboard screenshots, chart screenshots, alert conditions that attach images, and scheduled emails or Slack deliveries. Run every case on staging under the old Selenium setup and the new Playwright setup, and store the outputs side by side. Compare dimensions, fonts, color rendering, legends, filters applied at send time and whether charts finished loading before capture. The step is done when every difference is logged against a case, each one is marked as accepted or blocking, and the owner of each report has approved the accepted differences in writing.
Fix dashboards and schedules that tile unexpectedly
Superset 6.0.0 added tiled Playwright screenshots, on by default, for dashboards with 20 or more charts or taller than 5000 px. Find the dashboards that cross either threshold, and check the stitched output for seams, repeated headers, cut-off charts and missing lazy-loaded content. Adjust chart layout, reduce chart count on the report view, or split the dashboard into linked views where the output is not usable. Review schedules that send these dashboards, because a tiled image can change email size and inbox rendering. The step is done when every tiled dashboard in the matrix produces output the report owner accepts, and the changes are recorded in version control or the change log.
Upgrade production in a change window
The operations lead schedules a change window with the business owners of the reports, announces it, and confirms the rollback steps with the on-call team. Take a fresh metadata database backup immediately before the upgrade and keep it until the post-cutover check is complete. Deploy the new image, run the database upgrade and initialization steps the upgrade guide describes, and switch the worker to the Playwright image. If a blocking failure appears, restore the backup and redeploy the previous image, which the first step recorded. The step is done when the production web and worker pods report healthy and one manual screenshot renders correctly.
Run a post-cutover check of scheduled sends
After cutover, the team confirms that scheduled reports and alerts fire at their configured times and deliver the expected images. Compare the first set of sends against the matrix results from staging, and check worker logs for browser launch errors, timeouts and missing dependencies. Ask each report owner to confirm receipt and readability over the next full schedule cycle. Keep the retained backup and previous image until this check is signed off, then record the final state, the image digest and any accepted differences in the change log. The step is done when every scheduled report has been confirmed by its owner and no open blocking issues remain.
What makes the screenshot migration longer or shorter
This table lists the factors that most change how much work the Playwright switch takes, with what each one affects and what to confirm before scoping. Use it to see which answers in your environment push the effort up or down. Effort is set by the written scope agreed before work starts, not by a published rate, so treat each row as a question to answer during planning.
| Driver | Effect on effort | What to confirm |
|---|---|---|
| Active alerts and reports and their recipient channels | More schedules and channels mean more test sends, more checks that each message still renders and more recipients to notify of image changes | Count of active alerts and reports, which channels (email, Slack or other) receive them, and who owns each schedule |
| Dashboards above the tiling thresholds | Tiled screenshots are on by default in 6.0.0 for dashboards with 20 or more charts or taller than 5000 px, so large dashboards need output review | Number of dashboards that meet either threshold and whether tiled output is acceptable to report consumers |
| Custom chart plugins and dashboard styling | Custom plugins, fonts and theme overrides can render differently in headless Chromium, which adds visual comparison work | Which plugins, custom fonts and theme settings appear in scheduled reports and whether they load from internal assets |
| Existing Chromium setup in the worker image | A worker image that already contains a working Chromium and matching Playwright dependencies shortens the build, while a missing one adds image work | Whether your current worker image includes Chromium, how it is built, and whether your image registry allows the added packages |
| Worker and cache topology | Screenshot tasks run through workers and the caching layer, so more worker replicas and separate queues add configuration and load testing | Number of Celery worker and beat instances, Redis or other cache layout, and whether screenshot work shares queues with other tasks |
| Upgrade path length from the current release | Moving from an older line means combining the Playwright change with other breaking changes, which lengthens regression testing | Current Superset release, the target release, and every breaking change listed in UPDATING.md for that range |
| Staging environment that matches production | A staging copy with the same data, roles, SMTP or chat integrations and worker layout allows real report testing, while a partial copy pushes testing to production | Whether staging has the same metadata database version, worker setup, outbound mail or chat access, and a sample of production dashboards |
How to roll back a failed screenshot cutover
Decide in advance where the rollback point sits, because the cost of reversing the change grows with each step. There are three points to plan for: before the metadata database migration runs, after the migration has run but before alert and report schedules are re-enabled, and after a live report or alert has already been delivered to recipients. Before the migration, rollback is simply keeping the current image running. After the migration, the database no longer matches the older code, so you cannot reverse the change by redeploying alone. After a live send, no rollback can recall the email or Slack message that went out, so the goal becomes preventing a second bad send and documenting what recipients received.
Two levers reverse the cutover: restoring the metadata database backup taken before superset db upgrade, and redeploying the previous image tag. Use both together after a migration, because an old image running against a migrated schema is an unsupported state. Pause every alert and report schedule for the whole window, so a half-configured Playwright or Chromium setup cannot fire screenshots to stakeholders while you work. Confirm the restore procedure on a copy of production before the cutover, including how long the restore takes on your database size and whether scheduled jobs in the Celery worker queue are purged or replayed afterward.
Before you start, check the target release notes and UPDATING.md for any migration that cannot be reversed by restoring a backup, and ask your vendor or the release notes author to confirm it for your target version. If a migration is one-way, the restore point is the database backup, not the image tag, and the cutover should only proceed after that backup has been verified. Record the decision owner, the time at which schedules were paused and the time they were resumed, so the rollback is auditable.
Questions teams ask before moving reports to Playwright
How much does the Playwright migration cost and what drives the price?
The cost depends on the written scope, which usually covers the number of alerts, reports and thumbnails in use, the dashboards that need tiled screenshot testing, the environments to change (development, staging and production), and the image or deployment method you run. Most DeployOpen engagements are fixed-scope, so the price follows from a scope agreed in writing before work starts. One-time work includes the inventory, configuration changes, image rebuilds, and verification of report output. Recurring costs are your own infrastructure and any retainer you choose for later upgrades. DeployOpen does not publish a price list, so ask for a quote that lists each deliverable, the environments included, and what is excluded.
How long does moving reports and thumbnails to Playwright take?
Duration depends on how many report schedules and dashboards you have, how many environments must be tested, whether your Superset image is custom built, and how quickly your owners can review screenshots. Teams with a small set of reports and a standard image usually move faster than teams with many custom dashboards, large tiled layouts or a locked change window. The timeline should be stated in the written scope with milestones for staging validation and production cutover. Ask for a schedule that names the dependencies on your side, such as access approvals and sign-off dates.
What must our team provide before the migration starts?
Plan to provide the following before work starts:
- Access to the Superset instance, its metadata database and the container or deployment pipeline used to build it
- A staging environment that mirrors production closely enough to test report delivery
- An inventory of alerts, reports and dashboards that send screenshots, with their owners and recipients
- A named owner for each dashboard who can approve screenshot output
- A change window that fits your release process
Confirm these items with your team during scoping so the quote reflects what is actually available.
Can our internal team do the migration alone, and what skills does it need?
An internal team can do the work if it has people comfortable operating Superset, packaging Python dependencies, building container images and running Chromium in headless mode. The Playwright change touches the browser that renders screenshots, so the team also needs to test report output visually and manage the worker and caching components that generate reports. Consider whether the people with these skills have time during the change window, and whether someone will own the result after go-live. Many teams combine internal ownership with an external review of the scope and test plan.
Can tiled screenshots for large dashboards be turned off?
Superset 6.0.0 added tiled Playwright screenshots, which are on by default for dashboards with 20 or more charts or taller than 5000 px. Before changing that behavior, confirm the exact configuration key and its default in your installed version using the alerts and reports documentation and the release notes in UPDATING.md. Then test a representative set of large dashboards with the setting changed, because turning tiling off can alter how tall dashboards are captured in emails and reports. Record the result in your test plan before changing production.
What happens if Superset 7.0.0 is released on a different date than the release candidate?
The release candidate tells you the direction of the release, not its final date or final content. Apache Superset 7.0.0rc2 is listed on the GitHub releases page as a pre-release dated October 16, 2026, so plan for the final date to move. Keep your Playwright migration on the 6.x line until the final 7.0.0 release notes and UPDATING.md are published, then confirm the breaking changes that apply to your deployment. If the final release differs from the candidate, update the plan and test again in staging.
How DeployOpen scopes and delivers a Superset screenshot migration
DeployOpen plans, builds, tests and hands over the move of Superset report and thumbnail screenshots from Selenium to Playwright inside your own infrastructure. Each engagement starts from a written, fixed scope so that the screenshot path, rendering checks and handover are agreed before any change is made.
How we scope
- Inventory every alert, report and thumbnail that depends on the current Selenium screenshot path, including owners and delivery channels.
- Confirm the Superset version in use and the target release, with the Playwright and headless Chromium runtime planned for your hosts.
- Agree in writing which dashboards get tiled screenshot testing and which report formats and recipients are in and out of scope.
How we build
- Replace the Selenium and WEBDRIVER_TYPE settings with a Playwright and Chromium worker configuration in a staging environment first.
- Set tiling behavior for large dashboards, reviewing the 20-chart and 5000 px defaults against your layouts before rollout.
- Run side-by-side report comparisons on representative dashboards, recording image differences, fonts, timing and failed deliveries.
How we hand over
- Deliver a runbook covering the worker and caching components, the Chromium version pinned for your images and the rollback steps.
- Provide a test record listing each report and thumbnail checked, the expected output and the accepted visual differences.
- Walk your operations and analytics owners through alert delivery checks and the steps to confirm the next report run after a change.
How we support
- Engagements are fixed-scope, so the work, deliverables and timeline are agreed in writing before the migration starts.
- Ongoing support, upgrades and continuous testing for report output are available as a retainer after handover.
- Ask any proposal to state which tests are included, who owns the staging environment and how Superset upgrade notes will be reviewed.
