Skip to main content
RapidDev - Software Development Agency
retool-tutorial

How to Use Retool's Built-In Analytics Tools

Retool's Usage Analytics dashboard (Business+ plan) is at Settings → Usage Analytics. It shows app views, active users, query execution volumes, error rates, and performance grades across your org. Use it to identify heavily-used apps for optimization, unused apps for cleanup, and users who need training. Not available on Free or Pro plans.

What you'll learn

  • Access the Retool Usage Analytics dashboard from the admin Settings panel
  • Read app usage metrics: views, unique users, query execution counts, and error rates
  • Use the Performance tab to identify apps with low performance grades
  • Filter analytics by date range, app name, and user groups
  • Understand what metrics are available on each Retool plan tier
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Beginner6 min read15-20 minRetool Cloud (Business and Enterprise)Last updated March 2026RapidDev Engineering Team
TL;DR

Retool's Usage Analytics dashboard (Business+ plan) is at Settings → Usage Analytics. It shows app views, active users, query execution volumes, error rates, and performance grades across your org. Use it to identify heavily-used apps for optimization, unused apps for cleanup, and users who need training. Not available on Free or Pro plans.

Quick facts about this guide
FactValue
ToolRetool
DifficultyBeginner
Time required15-20 min
CompatibilityRetool Cloud (Business and Enterprise)
Last updatedMarch 2026

What Retool's Usage Analytics Tells You About Your Apps

Retool's Usage Analytics is an admin-level dashboard that gives you aggregate metrics about how your organization uses Retool. Unlike individual app debugging (which is covered by the Debug Panel), Usage Analytics shows org-wide patterns: which apps are used most, which queries are slowest, how many errors are occurring across all apps, and which users are most active.

This information is valuable for three use cases: (1) Performance prioritization — identify the highest-traffic apps that deserve optimization investment. (2) App hygiene — find stale apps that no one uses and should be archived. (3) Adoption tracking — monitor whether new apps are being adopted after rollout.

Usage Analytics requires the Business plan. Free and Pro plan users can access limited debug information through the Debug Panel.

Prerequisites

  • Admin access to your Retool organization
  • Retool Business or Enterprise plan (Usage Analytics is not available on Free or Pro)
  • At least a week of app usage history for meaningful data

Step-by-step guide

1

Access the Usage Analytics dashboard

Log in to Retool as an admin. Navigate to Settings (gear icon, bottom-left) → Usage Analytics. The dashboard loads with an overview of your organization's Retool usage. If you see a 'Upgrade your plan' message instead, your organization is on the Free or Pro plan which does not include Usage Analytics. The dashboard shows a date range selector at the top right — set it to the last 30 days for a meaningful baseline view.

Expected result: Usage Analytics dashboard loads showing aggregate metrics for your Retool organization.

2

Review app-level usage metrics

The App Usage section shows a table of all apps with their usage metrics: Total views, Unique users, Avg load time, Error rate, and Last accessed date. Sort by Total views to see your most-used apps — these deserve the most optimization investment. Sort by Last accessed to find stale apps (last accessed 90+ days ago) that could be archived to reduce clutter. Click on any app name to see its individual usage breakdown including a time-series view of daily views.

Expected result: App usage table shows which apps are heavily used, which are stale, and which have high error rates.

3

Identify high-error-rate apps

Sort the app usage table by Error rate (descending). Apps with error rates above 5% warrant immediate investigation. Click on a high-error-rate app to see the breakdown: which queries are failing, what error types are occurring, and at what times of day errors spike. High error rates often indicate: broken API integrations, expired credentials, or recently-broken database schema changes.

Expected result: List of apps with error rates above acceptable thresholds. Click-through to specific error types for each app.

4

Review query execution statistics

Navigate to the Queries section in Usage Analytics. This shows aggregate query execution metrics across all apps: total query executions per day, average query duration by resource, error rate by query name, and the slowest queries by average execution time. Sort by 'Avg duration (ms)' to find the slowest queries in your org — these are your top candidates for SQL optimization and caching. Sort by 'Error rate' to find queries that frequently fail.

Expected result: Query statistics table shows slowest queries and highest-error queries across all apps in the org.

5

Track user activity and adoption

The Users section shows per-user activity: apps accessed, queries triggered, and last active date. Filter by user group to see adoption rates by team. For a new app rollout, check whether your target user group is actually using the app — low adoption may indicate training needs or UX issues. Identify power users (highest query count) who might provide valuable feedback. Identify inactive users who have accounts but never log in.

Expected result: User activity data shows adoption rates, active users per group, and inactive accounts.

6

Use analytics to prioritize optimization work

Combine the app usage data to create a prioritization matrix: High usage + High error rate = Critical fix needed. High usage + Slow load time = Performance optimization needed. Low usage + High complexity = Candidate for archiving or simplification. High usage + Fast load time = Your best apps — document what they do right. Review this matrix monthly to allocate engineering time to the highest-impact Retool improvements.

Expected result: Prioritized list of apps for optimization work based on usage volume and quality metrics.

Complete working example

SQL Query: analyzeRetoolUsageData (if exporting to BI tool)
1-- This query pattern is for Enterprise customers who export
2-- Retool audit log data to their own data warehouse
3-- and want to build custom analytics dashboards
4
5-- Note: Standard Usage Analytics uses Retool's UI, not SQL.
6-- This is only relevant if you stream audit logs to Datadog/Splunk/BigQuery.
7
8SELECT
9 DATE_TRUNC('day', timestamp) AS day,
10 app_name,
11 COUNT(*) AS total_events,
12 COUNT(DISTINCT user_email) AS unique_users,
13 COUNT(CASE WHEN event_type = 'query_execution' THEN 1 END) AS query_executions,
14 COUNT(CASE WHEN event_type = 'query_error' THEN 1 END) AS query_errors,
15 ROUND(
16 COUNT(CASE WHEN event_type = 'query_error' THEN 1 END)::float /
17 NULLIF(COUNT(CASE WHEN event_type = 'query_execution' THEN 1 END), 0) * 100,
18 2
19 ) AS error_rate_pct
20FROM retool_audit_events
21WHERE timestamp >= NOW() - INTERVAL '30 days'
22GROUP BY 1, 2
23ORDER BY 3 DESC;

Common mistakes

Why it's a problem: Expecting Usage Analytics on a Free or Pro plan

How to avoid: Usage Analytics requires the Business plan. On lower plans, use the Debug Panel's Performance tab for per-app performance insights and check the Audit Log (Settings → Audit Log) for event history.

Why it's a problem: Treating a high view count as the only indicator of app importance

How to avoid: High views with low unique users may indicate one person refreshing repeatedly. High unique users with moderate views indicates broader organizational adoption. Look at both metrics together for a complete picture.

Why it's a problem: Not checking Usage Analytics after a major app release, missing early adoption signals

How to avoid: Check Usage Analytics 24-48 hours after releasing a new app or major feature. Early view/error data tells you if users found it and if it's working correctly before issues compound.

Best practices

  • Review Usage Analytics monthly as part of your Retool maintenance routine
  • Set an error rate threshold (e.g., >5%) as an alert target — apps exceeding this need investigation
  • Archive or delete apps with zero views in the last 90 days to keep the app library clean
  • Use user adoption data to identify teams that might benefit from Retool training
  • For Enterprise plans, configure audit log streaming to Datadog or Splunk for more granular long-term analytics

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

I'm a Retool admin on the Business plan. I want to use Usage Analytics to: (1) find our most-used apps and prioritize them for performance optimization, (2) identify apps with high error rates that need fixing, (3) find stale apps not used in 90+ days for cleanup, (4) track adoption of a new app launched last week. Walk me through where to find each metric in the Usage Analytics dashboard and what thresholds I should use to flag issues.

Retool Prompt

Navigate to Retool Settings → Usage Analytics. Sort the App Usage table by (1) Total views descending to find top apps, (2) Error rate descending to find broken apps, (3) Last accessed ascending to find stale apps. In the Queries section, sort by Avg duration to find slow queries. Explain what each metric means and what action to take when the metric exceeds a threshold.

Frequently asked questions

How long does Retool retain Usage Analytics data?

Retool retains Usage Analytics data for 90 days in the UI dashboard. For longer retention, Enterprise customers can configure audit log streaming to an external service (Datadog, Splunk, or S3) which retains data indefinitely based on the external service's retention policies.

Can individual app editors see Usage Analytics for their own apps?

No — Usage Analytics is an admin-only view in Settings. App editors cannot access org-wide metrics. Admins can share specific app performance data by exporting screenshots or querying the audit log and sharing results.

Does Usage Analytics track what data users are accessing in Retool queries?

Usage Analytics tracks query execution events (query name, timestamp, user, success/failure) but does not capture the actual data returned by queries or the parameter values used. For data-level audit logging (what records were read or modified), you need to implement application-level audit logging in your own database.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Learning is great. Shipping is faster with help.

Our engineers have built 600+ apps on Retool and the tools around it. If your project needs to be live sooner than your learning curve allows — book a free consultation.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.