1.2 The timechart Command & Time-Series Visualizations

Splunk Core Certified Power User Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Exam Facts, Logistics & Test-Taking Strategy 0.2 Splunk Knowledge Objects & Search Pipeline Architecture

2 Chapter 1: Transforming Commands for Visualizations

1.1 The chart Command & Multi-Dimensional Aggregations 1.2 The timechart Command & Time-Series Visualizations 1.3 Transforming Options: limit, useother, usenull, and Split-By Clauses

3 Chapter 2: Filtering and Formatting Results

2.1 The eval Command & Core Evaluation Functions 2.2 Filtering Data: search vs. where Commands 2.3 Handling Missing Data with fillnull

4 Chapter 3: Correlating Events & Transactions

3.1 Understanding Transactions & Event Grouping Concepts 3.2 Configuring transaction Constraints: maxspan, maxpause, startswith, endswith 3.3 Analyzing Transaction Output Fields: duration & eventcount 3.4 transaction vs. stats: Performance & Architectural Trade-offs

5 Chapter 4: Creating and Managing Fields

4.1 Regular Expression Extractions with Field Extractor 4.2 Delimiter-Based Extractions with Field Extractor 4.3 Field Extraction Management, Permissions & Search-Time Precedence

6 Chapter 5: Field Aliases and Calculated Fields

5.1 Creating and Using Field Aliases 5.2 Creating and Configuring Calculated Fields 5.3 Aliases vs. Calculated Fields in the Search Execution Pipeline

7 Chapter 6: Tags and Event Types

6.1 Creating and Using Event Types 6.2 Creating and Managing Tags 6.3 Combining Tags and Event Types for Data Classification

8 Chapter 7: Creating and Using Search Macros

7.1 Creating Basic Search Macros & Backtick Syntax 7.2 Macro Arguments, Validation & Evaluation Functions 7.3 Macro Scoping, Permissions & Troubleshooting

9 Chapter 8: Creating and Using Workflow Actions

8.1 Workflow Action Architecture & Field/Event Context 8.2 Creating GET and POST Workflow Actions 8.3 Creating Search Workflow Actions & Dynamic Secondary Searches

10 Chapter 9: Data Models and Pivot

9.1 Data Model Architecture & The Pivot Tool 9.2 Creating and Structuring Datasets & Hierarchies 9.3 Accelerating Data Models & TSIDX Acceleration

11 Chapter 10: Common Information Model (CIM)

10.1 The Splunk Common Information Model (CIM) & Normalization 10.2 CIM Knowledge Objects, Data Models & Schemas 10.3 Normalizing & Validating Data with the CIM App / datamodel command

1.2 The timechart Command & Time-Series Visualizations

Key Takeaways Explain This Topic AI

The timechart command is a specialized transforming command that automatically bins events along the internal _time field as the implicit primary X-axis dimension.

Unlike chart (which supports up to two split-by fields), timechart allows at most ONE split-by field via the by clause because _time is already locked as the row dimension.

Chronological time buckets can be explicitly configured using span=<interval> (e.g., span=5m , span=1h , span=1d ) or bins=<N> ; if omitted, Splunk dynamically selects an optimal span based on the search time window.

By default, timechart enforces continuous time ( cont=true ), ensuring that time buckets with zero events are included as empty intervals to preserve chronological scale integrity.

Built-in rate normalization functions ( per_second() , per_minute() , per_hour() , per_day() ) convert metric totals into standardized rates regardless of the underlying bucket span length.

Last updated: August 2026

1.2 The timechart Command & Time-Series Visualizations

Time-series analysis is the cornerstone of operational intelligence and security monitoring in Splunk. While the general-purpose chart command allows any categorical field to serve as the row dimension, the timechart command is purpose-built to aggregate metrics across time. It automatically groups events into chronological buckets using the internal _time timestamp field. Understanding how timechart manages bucket spans, enforces split-by limits, normalizes rates, and handles continuous timelines is essential for building robust dashboards and excelling on the Splunk Core Certified Power User exam.

1. The Architecture of timechart

Under the hood, timechart is an optimized, native C++ composite transforming command. It combines three distinct operations into a single high-performance pipeline stage:

Temporal Binning: Discretizing timestamps into uniform intervals using the bin (or bucket ) command on _time .

Statistical Aggregation: Calculating summary metrics across buckets and dimensions using stats .

2D Tabular Formatting: Pivoting secondary dimensions into wide series columns using chart . +-------------------------------------------------------------------------------------+

| The `timechart` Execution Equivalence Model |
+-------------------------------------------------------------------------------------+
| Native Query: |
| `... | timechart span=1h avg(cpu_usage) by host` |
| |
| Is functionally equivalent to the manual pipeline: |
| `... | bin _time span=1h` |
| ` | stats avg(cpu_usage) as avg_cpu by _time, host` |
| ` | chart avg_cpu over _time by host` |
+-------------------------------------------------------------------------------------+

Why Use Native timechart ?

Engine Optimization: Native timechart executes significantly faster and consumes far less memory on the Search Head and Indexers than manually chaining bin , stats , and chart .

Automatic Continuity ( cont=true ): It automatically fills gaps in time where zero events occurred, preventing false slope drops in line charts.

Rate Function Support: It provides specialized rate functions like per_hour() and per_minute() that dynamically normalize metrics to fixed time units.

2. The Single Split-By Field Rule

A fundamental architectural rule that appears on nearly every Splunk Power User exam is the split-by limit in timechart :

chart supports up to two split-by fields ( over <field1> by <field2> or by <field1>, <field2> ).

timechart supports at most ONE split-by field via the by clause because the primary row dimension is always implicitly locked to _time . # VALID TIMECHART EXAMPLES:

index=web | timechart count
index=web | timechart span=1h avg(bytes) as avg_bytes
index=web | timechart span=15m count by status
index=web | timechart span=1d sum(bytes) as total_bytes by host

# INVALID TIMECHART EXAMPLES (SYNTAX ERRORS):

index=web | timechart count by host, status <-- ERROR: More than 1 split-by field!

index=web | timechart count over _time by host <-- ERROR: 'over' clause not allowed!

What If You MUST Split by Two Fields Over Time?

If you need to analyze metrics broken down by time AND two additional categorical fields (e.g., _time , host , AND status ), you cannot use timechart . You must use bin followed by stats : index=web sourcetype=access_combined

| bin _time span=1h
| stats count by _time, host, status

This produces a flat, multi-column table containing all three dimensions.

Loading diagram... The timechart Data Processing and Visualization Pipeline

3. Controlling Time Buckets: span vs. bins

When grouping events into time intervals, you can explicitly configure bucket sizes using the span argument, constrain the total bucket count with bins , or allow Splunk to determine the span automatically.

Explicit Time Intervals ( span )

The span argument sets a fixed duration for each time bucket. Splunk SPL supports the following time unit abbreviations:

Unit Abbreviation Temporal Unit Example Usage Description
us / ms Microseconds / Milliseconds span=500ms High-frequency telemetry and sub-second metrics
s / sec Seconds span=30s Real-time streaming monitoring and short spikes
m / min Minutes span=5m , span=15m Standard operational application and web monitoring
h / hr Hours span=1h , span=4h Daily trends, server load, and traffic patterns
d / day Days span=1d , span=7d Weekly reporting, capacity planning, and SLA tracking
w / week Weeks span=1w Long-term macro trends and cyclical analysis
mon / month Calendar Months span=1mon Monthly billing, compliance, and growth summaries
y / yr Calendar Years span=1y Multi-year archival analysis

Warning

Syntax Trap: Notice that 1m represents 1 minute , while 1mon represents 1 month . Using span=1m on a 1-year search will attempt to create over 525,600 buckets, causing massive memory overhead or search truncation!

Constraining Bucket Counts with bins

Instead of specifying a fixed span length, you can request an approximate number of time buckets using bins=<integer> : index=web

| timechart bins=50 count by status

Splunk calculates the total duration of the search time window, divides it by 50, and rounds to the nearest sensible time unit (e.g., 5 minutes, 1 hour, 1 day).

Automatic Span Calculation

When neither span nor bins is defined, Splunk automatically selects an optimal span based on the search time window selected in the Time Range Picker and the screen resolution of the browser:

Search Range: Last 15 minutes -> Auto Span: 10 seconds or 30 seconds
Search Range: Last 24 hours -> Auto Span: 30 minutes or 1 hour
Search Range: Last 7 days -> Auto Span: 1 hour or 4 hours
Search Range: Last 30 days -> Auto Span: 1 day
4. Single-Series vs. Split-By Timecharts

The structure of the output table depends directly on whether a by clause is specified.

Scenario A: Single-Series Timechart (No by Clause) index=web
| timechart span=1h count as request_count, avg(response_time) as avg_latency
Output Data Structure: +---------------------+---------------+-------------+
| _time | request_count | avg_latency |
+---------------------+---------------+-------------+
| 2026-08-24 00:00:00 | 12450 | 142.5 |
| 2026-08-24 01:00:00 | 8320 | 118.2 |
| 2026-08-24 02:00:00 | 4100 | 95.8 |
+---------------------+---------------+-------------+

In a single-series timechart, each aggregation function forms its own column. This is ideal for dual Y-axis charts (plotting count on Left Y-Axis and latency on Right Y-Axis).

Scenario B: Multi-Series Split-By Timechart (With by Clause) index=web
| timechart span=1h count by status
Output Data Structure: +---------------------+-------+-------+-------+-------+-------+
| _time | 200 | 301 | 404 | 500 | OTHER |
+---------------------+-------+-------+-------+-------+-------+
| 2026-08-24 00:00:00 | 11800 | 450 | 180 | 20 | 0 |
| 2026-08-24 01:00:00 | 7900 | 310 | 95 | 15 | 0 |
| 2026-08-24 02:00:00 | 3950 | 110 | 35 | 5 | 0 |
+---------------------+-------+-------+-------+-------+-------+

When a by clause is added, distinct values of that field form individual series columns, enabling stacked area, stacked column, or multi-line graphs.

5. Timeline Continuity: The cont Argument

In standard statistical operations, if no events match a search for a specific time interval, that interval produces no output. In a time-series graph, omitting missing time intervals causes the X-axis to compress, distorting the perception of time.

To prevent this, timechart defaults to cont=true (continuous) :

cont=true (Default): Splunk generates a continuous timeline spanning the entire search window. Missing time buckets are included with null or 0 values.

cont=false : Splunk suppresses empty time buckets, returning rows only for intervals containing actual matching event data. Continuous Timeline (cont=true, Default):

+---------------------+-------+
| _time | count |
+---------------------+-------+
| 2026-08-24 08:00:00 | 450 |
| 2026-08-24 09:00:00 | 0 | <-- Preserves 09:00 gap on X-axis
| 2026-08-24 10:00:00 | 520 |
+---------------------+-------+

Non-Continuous Timeline (cont=false):

+---------------------+-------+
| _time | count |
+---------------------+-------+
| 2026-08-24 08:00:00 | 450 |
| 2026-08-24 10:00:00 | 520 | <-- 09:00 bucket is completely omitted
+---------------------+-------+

When to Use cont=false :

When analyzing sparse, sporadic datasets (such as critical security alerts or infrequent cron errors) where 99% of time buckets are empty and you only want to inspect active event windows in a tabular report.

6. Rate Normalization Functions: per_minute() , per_hour() , per_second()

A critical challenge in dashboard engineering occurs when users change the dashboard time range. If a dashboard panel aggregates requests using timechart count with auto-span:

Over a 1-hour search, the span might be 1 minute (e.g., 50 requests per bucket).

Over a 24-hour search, the span might be 1 hour (e.g., 3,000 requests per bucket).

To the end user, the metric appears to skyrocket from 50 to 3,000 simply because the bucket size increased!

To display consistent, normalized rates regardless of the underlying bucket span, Splunk provides built-in rate functions:

Rate Function Normalization Base Mathematical Formula
per_second(field) or per_second(count) Standard 1-second rate Value = (Metric / Span Seconds) * 1
per_minute(field) or per_minute(count) Standard 60-second rate Value = (Metric / Span Seconds) * 60
per_hour(field) or per_hour(count) Standard 3,600-second rate Value = (Metric / Span Seconds) * 3600
per_day(field) or per_day(count) Standard 86,400-second rate Value = (Metric / Span Seconds) * 86400

Step-by-Step Calculation Example:

Suppose you run the following search over a 15-minute span ( span=15m ): index=web
| timechart span=15m per_hour(count) as requests_per_hr by host

If web01 generates 600 requests during a specific 15-minute bucket:

Bucket duration = 15 minutes = 900 seconds.

Normalization factor for per_hour = 3,600 seconds (or 60 minutes).

Calculation:

Rate = (600 requests / 15 minutes) * 60 minutes = 40 * 60 = 2,400 requests/hour

Even if the dashboard span changes to span=5m or span=1h , the normalized metric remains directly comparable.

7. Advanced Inline eval in timechart

You can perform complex conditional aggregation and arithmetic transformations directly inside timechart : index=web sourcetype=access_combined

| timechart span=1h
count(eval(status>=200 AND status<300)) as http_2xx,
count(eval(status>=400 AND status<500)) as http_4xx,
count(eval(status>=500)) as http_5xx,
eval(round(avg(bytes)/1024, 2)) as avg_kb_per_req,
eval(round(count(eval(status>=500)) / count * 100, 2)) as error_percentage

This single query generates five synchronized time-series metrics per hour, perfect for comprehensive service health monitoring panels.

8. Summary of Common Exam Pitfalls for timechart

Two Split-By Fields: Never write timechart count by host, status . It is an invalid syntax. Use bin _time | stats count by _time, host, status instead.

The over Clause: Never use over in a timechart command (e.g., timechart count over _time by host ). The over keyword is strictly for chart .

Minute vs. Month Spans: Remember that span=1m is 1 minute, while span=1mon is 1 month.

Continuous Timeline Defaults: Remember that cont=true is the default behavior, which preserves empty time buckets.