7.2 Statistical Table Reports

Splunk Core Certified User Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Logistics 1.2 Study Strategy & Learning Path

2 Splunk Basics

2.1 Splunk Components 2.2 Uses of Splunk 2.3 Splunk Apps 2.4 User Settings & Basic Navigation

3 Basic Searching

3.1 Running Basic Searches 3.2 Setting Time Ranges 3.3 Contents of Search Results 3.4 Refining Searches 3.5 Using the Timeline 3.6 Working with Events 3.7 Controlling Search Jobs 3.8 Saving Search Results

4 Using Fields in Searches

4.1 Understanding Fields 4.2 Using Fields in Searches 4.3 The Fields Sidebar

5 Search Language Fundamentals

5.1 Basic Search Commands & Practices 5.2 The Search Pipeline 5.3 Specifying Indexes in Searches 5.4 table, rename, fields, dedup, and sort

6 Using Basic Transforming Commands

6.1 The top Command 6.2 The rare Command 6.3 The stats Command

7 Creating Reports and Dashboards

7.1 Saving and Editing Reports 7.2 Statistical Table Reports 7.3 Chart Visualization Reports 7.4 Creating Dashboards and Adding Reports 7.5 Editing Dashboards

8 Creating and Using Lookups

8.1 Lookup Concepts and File Examples 8.2 Creating Lookup Files and Definitions 8.3 Configuring Automatic Lookups 8.4 Using Lookups in Searches

9 Creating Scheduled Reports and Alerts

9.1 Scheduled Reports 9.2 Describing and Creating Alerts 9.3 Viewing Fired Alerts

7.2 Statistical Table Reports

Key Takeaways Explain This Topic AI

Statistical table reports display transforming-command results as rows and columns on the Statistics tab and as Visualization type Table.

Commands such as stats, top, and rare naturally produce tabular result sets that save cleanly as table reports.

Choose Table when exact values, multiple metrics, or sortable comparisons matter more than shape or trend imagery.

Save As Report after confirming Statistics looks correct so the table formatting and search travel together.

Table reports are ideal dashboard panels for ops triage where readers need precise counts, percentages, or ranked lists.

Last updated: August 2026

7.2 Statistical Table Reports

Objective 6.3 asks you to create reports that display statistics (tables) . On the User exam, this means recognizing when your search results are a statistical table , choosing the Table visualization when appropriate, and saving that view as a report teammates can reopen.

Tables are not “less advanced” than charts—they are the right answer when precision beats pictures.

What a Statistical Table Report Is

A statistical table report shows aggregated or ranked results as columns and rows—counts, averages, percentages, top values—rather than as a pie slice or line series. In Search you usually build it on the Statistics tab after a transforming command. On the Visualization tab, set the visualization type to Table when you want the same grid presentation saved with the report.

View What you see When it matters
Events Individual matching events Exploration before transforming
Statistics Tabular output of transforming commands Primary place tables are born
Visualization → Table Same stats rendered as a table viz Confirms what the saved report will show as a table
Typical producers of table-ready results

Command pattern Example result shape Good table report use
stats aggregations count , avg , sum by split-by fields KPI grids, multi-metric summaries
top field values with count and percent Ranked “most common” lists
rare least common values with counts/percents Outlier categories
table / fields after transforms Selected columns only Clean ops handoff tables
sort on stats output Ordered rows Leaderboards and triage queues

You already practiced top , rare , and stats in Domain 5.0. Domain 6.3 is about packaging those results as reports that display as tables .

Building a Table Report Step by Step

Bound the search with index, sourcetype, field filters, and time range.

Transform with stats , top , or rare (or a short pipeline that ends in a clear table).

Inspect the Statistics tab—column names and values should answer the business question.

Optionally open Visualization , choose Table , and tidy column formatting if needed.

Save As Report , name it clearly, set Private or App permissions.

Worked example: stats table index=web sourcetype=access_combined
| stats count as requests, avg(bytes) as avg_bytes by status
| sort - requests

Statistics might look like:

status requests avg_bytes
200 18420 1520.4
404 932 410.2
500 118 880.0

Save as HTTP Status Request Volumes . Visualization type Table keeps the exact numbers front and center—ideal when on-call staff must compare 404 vs 500 counts without interpreting a chart.

Worked example: top as a table index=security sourcetype=linux_secure action=failed
| top limit=10 user

top returns columns such as user , count , and percent . That is already a statistical table. Saving it as a report titled Top Failed Login Users creates a reusable ranked table for security review.

Worked example: rare as a table index=web sourcetype=access_combined
| rare limit=10 uri_path

Rare paths are often more useful as a table than as a pie chart (tiny slices are hard to read). A report named Least Common URI Paths preserves that ranked scarcity view.

When Table Beats Chart

Prefer a table when… Prefer a chart when…
Readers need exact values Readers need shape/trend at a glance
Many columns/metrics appear together One or two series tell the story
Ranking and percent columns matter Part-to-whole or time trends dominate
Sorting/scanning rows is the workflow Stakeholder slide-style visuals matter

Exam scenarios often describe “show counts and percentages for each category” or “list the top 10 values with count and percent.” Those phrases point to statistical table reports , not pie aesthetics.

Formatting and Clarity Tips (User Level)

Use meaningful column names via as ( count as failures ) so the saved table is self-explanatory.

Limit columns with fields or table after transforms when extra fields clutter the grid.

Sort intentionally ( sort - count ) so the first rows answer the question.

Keep titles specific: include the metric and the split ( Errors by Host , not Stats1 ).

Descriptions should state the time intent (“Last 24 hours failed logins by user”).

You do not need advanced CSS, Simple XML <format> deep-dives, or Dashboard Studio table cells for this objective. Stay with Search → Statistics/Table → Save As Report.

Saving Table Reports for Dashboards

Table reports are excellent dashboard panels because they:

Show precise numbers for ops and audit readers
Match the Statistics output people already trust from Search
Avoid misleading chart encodings when categories are numerous

In section 7.4 you will add such a report to a dashboard as a panel. For 6.3, the tested skill is creating the report that displays statistics as a table in the first place.

Exam Traps for 6.3

Trap Reality
Believing only charts can be saved as reports Tables are first-class report visualizations
Saving from Events view and expecting a stats grid Transform first; Statistics is where tables appear
Using a pie chart for a 25-column KPI grid Table is the clearer statistical display
Thinking top results are “not tables” top / rare / stats outputs are tabular
Dragging CIM data models into the answer User table reports come from search transforms
Mini Scenario Drill

Your manager wants a reusable view of the ten most common status codes with counts and percentages for the web index over the last 24 hours.

Strong approach: index=web sourcetype=access_combined
| top limit=10 status

Confirm Statistics → Save As Report → Visualization Table (if not already) → name Top 10 HTTP Status Codes → share to App when ready.

That workflow is objective 6.3 in one pass: transforming results, table display, saved report.