How to measure Apache Superset usage and adoption from the logs
A platform owner who has to show which teams use Superset, and which dashboards are dead weight, does not need a separate analytics tool to answer that. Superset's metadata database already records the activity that usage analysis depends on, so the work starts with confirming which activity records your version writes and how to query them. According to the Superset architecture documentation, the metadata database is one of the four core components, alongside the Flask and React application, the optional caching layer and the optional Celery worker and beat processes. That means the activity data lives in a database your team already runs, backs up and secures, and it stays inside your infrastructure.
This topic covers four measurements: monthly active users, dashboards that nobody opens, heavy queries that load the warehouse, and an admin dashboard built inside Superset itself so the figures are visible without a separate export. Before writing any query, confirm the log table contents for your exact Superset version. Ask your team to list the table names, the columns that record the user, the object and the timestamp, and whether query text and run times are stored. Event names and field meanings change between releases, so do not copy a query from another deployment or from an older guide without checking it against your own schema. Also confirm the retention behavior, because a table that is pruned after a fixed period limits how far back a monthly trend can reach.
Plan two decisions before the first report goes live. The first is who may see usage data, because the log rows reveal who viewed which dashboard and when, which is sensitive in many regulated settings and should follow the same access model as the rest of the platform. The second is how often the figures refresh and whether heavy analytical queries run against the production metadata database or a replica, since poorly bounded aggregations over a large log table can slow the application itself. Write the definitions down as well. Decide what counts as an active user in a month, whether a dashboard view with no chart interaction counts as use, and what period of inactivity makes a dashboard a candidate for retirement. These definitions matter more than the query syntax, because they determine the numbers your leadership team will read.
Which usage questions the logs can answer
Usage questions in Superset are answered from the metadata logs table, and each question depends on different fields and different assumptions. The cards below pair each question with the fields you must confirm in your own deployment and the limits of what the answer proves, so that a dashboard built on the logs does not overstate adoption.
Monthly active users
Counting distinct users with logged activity in each calendar month shows how many people touch Superset at all. Confirm which action types your deployment writes to the log, since a count based only on dashboard views will miss SQL Lab users, and confirm that the user reference resolves to a stable identity rather than a shared service account. A login alone is not a use of the data. Treat the count as an upper bound on engaged people, because a shared account or an automated API call can inflate it.
Dashboard adoption by team
Grouping dashboard activity by the team that owns the dashboard or by the roles of the viewing users shows which business areas rely on which content. Confirm that your deployment records a dashboard or slice reference on each event and that users map to teams through your identity provider or a maintained lookup table, not a manual spreadsheet that drifts. A team can appear inactive because its members use an embedded or public dashboard that the log records under a different identity.
Unused dashboards for retirement
Listing dashboards with no logged views over a chosen window identifies candidates for archiving or removal. Before you act on the list, confirm the window length against business cycles such as month-end or quarterly reporting, and confirm whether scheduled reports or alerts read those dashboards, since those deliveries may not appear as interactive views. Absence of views does not prove that no one depends on the data, so confirm the owner and any downstream consumers before retiring anything.
Heavy or slow queries
Ranking queries by execution time or by the database they hit points to charts and datasets that load the warehouse most. Confirm that your deployment logs query duration and the originating chart or SQL Lab session, and confirm whether the duration includes time spent waiting in a queue or in the caching layer. A slow result can come from the warehouse, the network or Superset itself, so the log identifies where to investigate but does not isolate the cause on its own.
Who edits versus views
Separating change events, such as dashboard saves, chart edits and dataset changes, from read events shows who maintains content and who only consumes it. Confirm that your deployment records update and create actions with the acting user, because some edit paths may not produce the same event type as the UI. A view proves that a request for the page was served, not that a person read or acted on the figures, so pair this question with the audit logging controls rather than treating views as evidence of decisions.
Choosing how to read usage data
This table compares four ways to answer who uses which dashboards: direct SQL against the metadata database, an admin dashboard built in Superset, exporting logs to a SIEM or warehouse, and spot checks in the Action Log view. Read each row for the access it needs and what it costs you in effort and retention, then choose the combination that fits your audit and reporting needs.
| Option | When it fits | Access it needs | Trade-off in effort and retention |
|---|---|---|---|
| Direct SQL on the metadata database | Ad hoc questions, one-off investigations and reports you can write once and rerun | Read-only database role on the Superset metadata database, scoped to the log and dashboard tables | Low setup effort, but every query depends on the table schema, which can change between Superset releases. Retention is whatever the metadata database keeps |
| Admin dashboard built in Superset | Routine adoption reviews shared with product owners, data stewards and platform leads | A dedicated analytics database connection, restricted dashboard access and row level security if audiences differ | Charts run against the same metadata database, so heavy queries can load the database. Requires ongoing upkeep as dashboards change |
| Export to a SIEM or warehouse | Audit trails that must be searched alongside other security events or kept for a long period | Event shipping configured in Superset, plus write access to the SIEM or warehouse and a service account to receive events | Highest setup effort, including event schema mapping and retention rules. Usually the only option that keeps history beyond the metadata database's own retention |
| Action Log view spot checks | Quick checks on a specific user, dashboard or time window during an investigation | Admin or appropriate built-in role with access to the Action Log view in the Superset interface | Fastest to use with no extra build, but it is manual, hard to aggregate across months and not a substitute for a retained audit record. Confirm current retention in your release |
Building an admin usage dashboard in Superset
This sequence turns the Superset metadata logs into an admin dashboard that answers who uses which dashboards, which ones sit unused, and which queries cost the most. Each step ends with a check so the numbers can be trusted before anyone relies on them.
Confirm the logs table and Superset version
Start by confirming which Superset version runs in your environment, since the Action Log schema and column names can differ between releases. Connect to the metadata database with a client your team already uses and confirm that the logs table exists and that it holds recent rows for dashboard views, chart queries and logins. Check the version in the Superset interface or the image tag, then compare the column names against the version's documentation. Done means you can list the columns you plan to use and show a row count that rises after you open a dashboard yourself.
Create a read-only metadata database connection
As an administrator, add a new database connection in Superset that points to the metadata database using a dedicated database account with SELECT privileges only. Keep this account separate from the account Superset uses for its own application database, and do not grant it write, DDL or role-changing permissions. Store the password in your secrets process rather than in the connection notes. Done means a test connection succeeds and a simple SELECT against the logs table returns rows, while an attempted INSERT or CREATE fails with a permission error.
Restrict the connection to an admin role
Limit who can see the metadata connection and the datasets built on it, because the logs record user identities, query text and dashboard activity. Assign the connection's data access to an admin-only role and confirm that analyst and viewer roles cannot open the database connection or the usage datasets. Review the role's permissions in the Superset role editor and test with a non-admin account that the datasets do not appear. Done means a non-admin test user cannot list, query or preview these datasets.
Build datasets for the three core questions
Create virtual datasets from SQL against the logs table, one for monthly active users, one for dashboard activity used to find unused dashboards, and one for heavy queries grouped by duration or row count. Each dataset should expose a clearly named date column, a user or dashboard identifier and a numeric measure. Join to user and dashboard tables only where the join key is confirmed in your schema. Done means each dataset previews rows in Superset and the grouped counts match a manual query you run in the database client.
Verify the datasets against known activity
Pick one dashboard and one user whose activity you know, such as a dashboard you open on purpose during a test session, and confirm each dataset reflects it. Check that the monthly active user count includes your test user for the current month, that the unused dashboard list omits the dashboard you just opened, and that the heavy query list shows a query you ran with a known long duration. Note any gap between the logs and the expected activity, such as views that are not logged, before building charts on top. Done means each known event appears in the right dataset and any gaps are written down.
Assemble the admin dashboard
Create the admin dashboard and add one chart per question: a time series for monthly active users, a table for unused dashboards with last viewed date, and a bar or table chart for heavy queries sorted by duration. Add a native filter for date range so admins can narrow the period, and avoid filters that expose individual query text to anyone outside the admin role. Set the dashboard so only the admin role can view it. Done means all three charts render from the datasets and the filter changes their results.
Check each chart against a known value
Compare every chart on the dashboard with a value you calculate independently, using the same date range in the database client. Confirm that the monthly active user figure matches a distinct user count, that the unused dashboard table matches a query for dashboards with no recent views, and that the heavy query ranking matches the sorted durations from a direct query. Record the check date and the Superset version next to the dashboard so later changes can be tested against the same baseline. Done means each chart matches its independent query for the same range, and the record is saved with the dashboard owner.
Protecting usage data and the people it describes
Usage analytics makes Superset's own activity records a sensitive dataset in their own right. The four cards below cover who can see the records, what a database-level exposure would reveal, how long personal activity is kept, and how the admin dashboard inherits the same controls as the rest of Superset.
Usage logs reveal who views sensitive data
The log table records which user opened which dashboard and when, so it is a map of who looks at payroll, customer or patient data. Treat it as sensitive even though it holds no query results. Before building any report on it, confirm which dashboards and datasets the log can reveal indirectly, for example through chart names or dataset titles that carry business meaning. Decide which roles may read raw log rows and which may only see aggregated counts.
Read-only metadata access exposes secrets
Analysts often ask for a read-only login to the metadata database to run usage queries. Superset stores database connection details in that database, and some fields are encrypted with the SECRET_KEY. A read-only role that can select from the connection table can still expose hosts, usernames and encrypted values that others could attempt to decrypt. Create a dedicated reporting role that can read only the log and user tables, and test that it cannot read the connection table.
Retention for personal activity records
Activity rows tie a named user to a timestamp and an object, which makes them personal data under most privacy regimes. Retention is a policy decision, not a Superset default you can assume. Agree with legal and HR how long raw rows are kept, when they are aggregated into counts without user identifiers, and who approves deletion. Check whether your backup schedule keeps older copies of the log table that your deletion policy must also reach.
Admin dashboard inherits the same access model
A usage dashboard built inside Superset is only as protected as its own permissions. If it is published to a broad role, or shared as a public dashboard, anyone with that access can read the personal activity behind it. Assign the dashboard to a restricted role, confirm that row level security and dataset permissions apply to the usage datasets, and review who holds admin rights, since those users can change access to every dashboard.
Questions teams ask before measuring Superset usage
How long does it take to build a usage dashboard in Superset?
The duration depends mostly on how much of the logs table is already understood and how many questions the dashboard must answer. A team that only needs monthly active users and a list of unused dashboards has a small query set to write and validate. Adding heavy query analysis, per-role breakdowns and retention views adds work for each question, because each one needs its own query, a check against known usage, and a review by the people who will read it. Ask any provider for a written scope that lists the questions, the data sources and the review steps, then estimate the duration from that list rather than from a general figure.
Can our internal team build this without outside help?
Yes, if the team has someone comfortable with SQL against the Superset metadata database, a working understanding of how Superset records dashboard views and queries, and an admin who can create datasets and dashboards in Superset. The harder parts are validating the logic, deciding which events count as active use and keeping the queries correct after an upgrade. Teams without those skills usually get the fastest result by pairing an internal owner with an outside reviewer for the first build, then maintaining the queries in-house. Either path works, and the decision mostly depends on who will own the results after handover.
What cost components should we expect for usage measurement?
Most of the cost is labor, split between defining the questions, writing and testing queries, building the Superset charts and dashboard, and documenting how each metric is calculated. The software itself is free because Superset is released under the Apache License 2.0 and has no paid edition. Recurring costs are smaller but real: someone must review the dashboard after upgrades, adjust queries when new features change the logs, and keep the metadata database backed up. Ask for a quote that separates one-time build work from any ongoing review or support, and that names who performs each task.
What do we need from the platform owner and the data team?
The platform owner must provide read access to the Superset metadata database, a place to create a dedicated dataset and dashboard, and a change window if the work touches production. The data team needs to explain what the logs table records, how user identities map to people, and which dashboards are official. Without those inputs, the team will argue about definitions instead of building. Confirm early whether reporting queries can run against the production metadata database or should run against a replica, since heavy queries on the metadata database can affect the application.
Can we use these usage numbers for licensing or chargeback?
Usage numbers from the logs table show activity that was recorded, not a verified count of contracted users. Superset has no paid edition, so there is no license count to match, but internal chargeback or cost allocation still needs agreed definitions. Shared accounts, deleted users, service accounts and dashboards viewed through embedded or public access can distort counts. Before anyone bills a department on these figures, agree on what counts as a user, which events count as use, and how the numbers are reconciled with the identity provider. Your finance and compliance teams should sign off on those rules.
How do Superset upgrades affect the logs table and our queries?
Upgrades can change table names, columns and how events are recorded, so queries that worked on one version may return wrong results or fail on the next. The upgrade guide asks you to back up the metadata database, run the database upgrade and initialization commands, test in staging first, and check UPDATING.md for breaking changes between versions. Add a step that reruns your usage queries in staging and compares the results to the production baseline. Keep the queries in version control so that changes are visible and can be reverted.
Will measuring usage slow down Superset or expose sensitive data?
Queries against the logs table add load to the metadata database, so run them on a schedule during quiet hours, limit the date range and avoid joining large tables on every page load. The dashboard itself exposes information about who viewed which dashboards and when, so restrict it to administrators and auditors and check it against your access model. Confirm which fields contain personal data and how long your organization keeps them. Logging policy and retention decisions belong to your security and compliance owners.
What to confirm in your environment before you rely on the numbers
Usage numbers from Superset are only as reliable as the metadata behind them. The cards below cover the storage, versioning and retention questions that decide whether a monthly trend or an unused-dashboard list will hold up when someone outside your team reviews it.
Log table schema by version
The usage queries in this topic read the logs table in the metadata database, and its columns can change between Superset releases. Before you write any query, confirm the exact column names and types in your running version against a fresh query of the table. Re-check after every upgrade, because a query that worked on one release can return empty or wrong results on the next. Keep the query text in version control next to the version it was tested on.
Non-production metadata databases
The default SQLite database from Quickstart and PyPI installs, and the PostgreSQL container from Docker Compose, are not recommended for production by the Superset architecture documentation. Usage history stored in either one is harder to back up, restore and keep consistent with the rest of your reporting. If your reporting runs on one of these, treat the numbers as a trial, and move the metadata database to a supported PostgreSQL or MySQL instance before you present trends to leadership. Confirm the supported versions for your database engine.
Log retention for monthly trends
Monthly active user counts need the log rows for every day of the month, and the logs table grows with every chart load and query. Confirm whether your team or a cleanup job deletes old rows, and how far back the table goes today. If you plan to compare quarters or years, decide the retention window before you start, and export monthly aggregates to a separate table or a warehouse so older trends survive any purge. Ask who owns the purge schedule.
Pre-release version in use
Pre-release builds such as 7.0.0rc2 are published for testing, and their schema, defaults and behavior can change before a stable release. Check the version string in your running deployment before you rely on usage figures for decisions. If you run a release candidate, treat the logs table as provisional and rerun your queries after you move to the stable release. Record the exact version alongside every report so a reviewer can reproduce the numbers.
How DeployOpen scopes and delivers Superset usage reporting
DeployOpen plans, builds and documents usage reporting for self-hosted Apache Superset inside your own infrastructure. We start from a written scope that names which metadata, dashboards and access questions the reporting must answer, then deliver the queries, admin dashboard and handover material your team keeps running.
How we scope
- We agree in writing which usage questions the reporting must answer, such as active users by month and unused dashboards.
- We confirm which Superset metadata database holds the logs table and who can read it.
- We record which roles and data sources the admin dashboard may show, so access rules stay intact.
How we build
- We write and test the usage queries against a staging copy of your metadata database before anything runs in production.
- We build the admin dashboard inside Superset with datasets, charts and filters that your team can review.
- We check that heavy-query reporting does not add load to the metadata database or the analytics warehouse.
How we hand over
- We document each query, its definition of an active user and the known limits of the logs table.
- We walk your administrators through the dashboard, the refresh schedule and how to change a metric.
- We deliver the scope, test results and configuration files in a form your team can maintain without us.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and reporting changes are available as a retainer, which we can scope for your Superset version.
- We recommend re-checking the queries during each Superset upgrade, using the project's upgrade guide, before relying on the numbers.
