If you cannot use chart commands, every search result will be a giant table of raw events, and you will never spot trends or patterns. For the SPLK-1003 exam, you need to know how to turn raw log data into meaningful visualisations so you can answer questions like 'What was the average response time over the last 24 hours?' or 'Which server had the most errors last week?' Chart and timechart commands are the tools that do that transformation.
Jump to a section
A simple way to picture Chart Commands and Formatting
The kitchen of a busy Sunday brunch spot, where three different cooks are all shouting for the same measuring cups at once.
You are the head chef, and you need to know how many pancakes each cook flipped in the last hour. You could stand over each cook and count manually, but that would take forever and you would miss the frittata order. Instead, you use a timer and a recipe card. The timer marks each event (a pancake flipped) with a timestamp. The recipe card tells you what you want to know: 'Show me a bar for each cook with the number of pancakes they flipped, and colour the bars by how fast they flipped them (under 30 seconds = green, over 30 seconds = red).' The timer is your data, the recipe card is your chart command. Now imagine you want to see how the pace of pancake flipping changed over the brunch shift. You use a different card — a timechart card — that automatically groups the flips into five-minute windows and draws a line for each cook.
The chart command and the timechart command are your two recipe cards. They save you from manually counting events (raw search results) and turn the chaos of the kitchen into a clear, shareable chart. Without them, you are just holding a list of every single pancake flip and trying to see a pattern with your bare eyes.
In Splunk, a search returns events — individual lines of log data. Raw events are like a pile of unstacked bricks. Chart commands are the mortar and blueprint that turn those bricks into a wall you can read.
A chart command is a transforming command. It takes a set of events, groups them by something (a field, a timestamp, a category), and then applies a statistical function (count, average, sum, min, max) to produce a single output table with rows and columns. That table can then be displayed as a column chart, bar chart, line chart, or pie chart. The syntax is: ... | chart <stats-function>(<field-to-aggregate>) BY <field-to-group-by>. For example: ... | chart count by status. This counts events for each unique value in the status field (like 200, 404, 500).
The timechart command is a specialised version of chart. It automatically uses _time as the field to group by, splitting events into time buckets (bins). You can set the bucket span with span=. For example: ... | timechart span=1h count by status. This creates a table where each row is an hour, and each column is a status value, showing how many events had that status in that hour. Timechart is the command you use when you want to see how a metric changes over time.
Why do these commands exist? Because raw events are too granular. Imagine monitoring 100 servers. Each sends a log line every second. In one day, you have 8.64 million events. A raw table of those events is useless. The chart command reduces millions of events to a few numbers: 'Server A: 50 errors, Server B: 30 errors.' That is the core value.
Formatting options let you change how the chart looks. The key formatting clauses are:
| chart count by host limit=5 — The limit option controls how many distinct values appear. Without it, if you have 1000 different hosts, you get a chart with 1000 bars, which is unreadable. limit=5 shows only the top 5.
| chart count over host — The over option designates which field provides the x-axis labels.by designates the series (grouped bars or lines). For a simple one-series chart, you use by alone. For a multi-series chart, you use over and by.
| chart useother=f — The useother option, when set to f (false), tells Splunk not to lump all the smaller values into an 'Other' bucket. This is useful when you want to see every value, even if there are many.
| timechart span=1h count usenull=f — The usenull option controls whether time buckets with zero events appear as gaps. usenull=t (true) shows a line dropping to zero. usenull=f (false) skips those buckets, connecting the line across the gap.
The formatting options are not just cosmetic. They change the data that gets sent to the charting engine. If you forget limit=5, Splunk tries to render a chart with 1000 bars, which visualises poorly and may not load at all. If you forget usenull=f, you might see misleading gaps that make a system look down when it was actually fine (just no events matched).
Real example: You run index=web sourcetype=access_combined | chart count by status. The result is a table: status 200 count 1500, status 404 count 30, status 500 count 5. Splunk's visualisation tool then renders a bar chart with three bars. If you add | chart count by status limit=2, you get only the top two statuses (200 and 404), and the 500 is hidden. That might hide an important error.
The over option is particularly tricky. | chart count over host by status produces a table where each row is a host, and columns are status values. This creates a stacked or grouped bar chart with hosts on the x-axis and statuses as coloured series. The equivalent using by alone would be | chart count over host by status — switching the order matters. In Splunk's chart command, the field after over becomes the x-axis. The field after by becomes the series (legend).
Beginners often confuse chart with stats. The difference: stats returns a table of numbers without any special formatting for a chart. chart returns a table that is pre-formatted to be fed into a visualisation. timechart is specifically designed for time-based bucketing. You could mimic timechart with bin _time span=1h | stats count by _time, status, but timechart is simpler and runs faster.
When you use timechart, you almost always want to set a span that matches your data's granularity. If you have data from one day, span=1h gives 24 data points — a good density. span=1m gives 1440 points, which might be too noisy. span=1d gives one point — useless. You learn to choose the right span by thinking: 'What time resolution do I need to see the pattern?'
Another key formatting option: | timechart count by status partial=f. The partial option controls whether the first and last time buckets are shown if they contain only partial data (e.g., the current hour is only half over). partial=f (false) hides those partial buckets so your chart doesn't show a misleading low count at the end.
Finally, both chart and timechart can have multiple series (the by clause) or a single series. A single series chart has one line or set of bars. A multi-series chart has multiple, which you distinguish by colour in the legend. The formatting options limit, useother, usenull, and partial apply to multi-series charts most often.
Start with a filtered search
Before you can chart anything, you need a set of events. Use a `search` command or a keyword filter to narrow down to the events you care about. For example, `index=web sourcetype=access_combined status=500` gets only the 500 errors. Filtering first is crucial because chart commands run on the resulting events and large result sets slow down both chart creation and rendering.
Choose chart or timechart based on the question
If the question asks 'How many errors per host?' use `chart`. If it asks 'How did the error count change over the last hour?' use `timechart`. Your choice determines which fields are available for the x-axis. `timechart` automatically uses `_time`, while `chart` lets you pick any field as the x-axis using the `over` clause.
Write the aggregation function and field
Every chart needs an aggregation function. Common ones: `count` (counts events), `sum(field)` (sums numbers), `avg(field)` (average), `min(field)`, `max(field)`. For `timechart`, you often just use `count` (e.g., `| timechart count`). If you want to sum a field like `bytes`, write `| chart sum(bytes) by host`.
Define the by and over clauses
For `chart`, decide which field provides the x-axis labels (`over`) and which field provides the series (`by`). For `timechart`, the x-axis is always `_time`, so you only need the `by` clause for series. Example: `| timechart count by status` creates a line for each status code over time.
Add formatting options to improve readability
Add `limit=5` to show only the top 5 series. Add `useother=f` if you want to see every distinct value without lumping. Add `usenull=f` to hide time buckets with zero events if you prefer a continuous line. Add `partial=f` to exclude partial time buckets at the search range edges. These options refine the output table before it becomes the chart.
Visualise the result
Splunk automatically shows the output table in the Statistics tab and a default chart in the Visualisation tab. You can then change the chart type (line, bar, column, pie) in the Visualisation tab. The chart command data is now ready for a dashboard panel or report.
An IT professional at a mid-sized e-commerce company uses Splunk to monitor the checkout process. Every user action on the checkout page generates a log event with sourcetype checkout_events. The fields include action (add_to_cart, remove_from_cart, start_checkout, purchase), user_id, product_id, and error_code.
On Monday morning, the company's product manager reports that the 'purchase' completion rate seems lower than usual on Sunday evening. The IT pro needs to investigate.
Step 1: Run a raw search to confirm the data exists: index=main sourcetype=checkout_events action=purchase. The raw table shows thousands of purchase events, each with a timestamp. Impossible to see a pattern.
Step 2: Use timechart to see purchases over time: index=main sourcetype=checkout_events action=purchase | timechart span=1h count. The resulting chart shows a line that drops steeply between 18:00 and 20:00 on Sunday. But the IT pro needs to know why.
Step 3: Break the chart down by error code: index=main sourcetype=checkout_events action=purchase | timechart span=1h count by error_code usenull=f. The chart now shows three lines: one for error_code=null (success), one for error_code=timeout, one for error_code=payment_declined. The IT pro sees that the payment_declined line spikes exactly when the total purchase count drops. The span=1h reveals that the spike started at 18:15 and lasted exactly 45 minutes.
Step 4: Zoom in with a finer span: ... | timechart span=5m count by error_code usenull=f. The chart now shows the spike started at 18:12 and ended at 18:57. The IT pro correlates this with a known payment processor outage window.
Step 5: The IT pro wants to present findings to the product manager. They use formatting to clean the chart. They add limit=3 to show only the top 3 error codes, useother=f to avoid lumping rare codes into 'Other', and set partial=f because the current Monday data is incomplete and they do not want a misleading last bucket. They export the chart as a PNG and paste it into a Slack message.
The business impact: Without the chart commands, the IT pro would have sifted through thousands of raw events and likely missed the 45-minute payment_declined spike. With the formatted timechart, they identified the root cause in under 10 minutes and enabled the product team to reroute traffic away from the failing payment gateway before the next peak hour.
A different scenario: The IT pro wants to know which product categories had the most abandoned carts this week. They run index=main sourcetype=checkout_events action=add_to_cart | chart count over product_category. But the chart shows 200 categories, making the x-axis unreadable. They add limit=10 and useother=t: | chart count over product_category limit=10 useother=t. Now the chart shows the top 10 categories and groups the remaining 190 into an 'Other' bar. The product manager can instantly see that 'Electronics' and 'Clothing' dominate cart additions, but the 'Other' bar is also large, suggesting 190 other categories also matter. The IT pro then adds | chart count over product_category limit=10 useother=f to show that the 'Other' bar disappears and instead reveals 200 bars — but they only use that for a CSV export, not the visual chart.
The formatting options are not just decoration. They directly affect what data the decision-makers see. Choosing limit=5 vs limit=10 can change which product categories get attention. Using usenull incorrectly can make a system look flaky when it was actually idle. An IT pro who masters these options becomes the person who can turn a firehose of logs into a single slide that explains the whole situation.
The SPLK-1003 exam tests chart and timechart commands heavily. Expect at least three to four questions about them, often combined with other commands like eval, rex, or where. The exam loves to test the differences between chart, timechart, and stats.
- Key topics the exam tests:
Syntax of chart and timechart: | chart <stats-function>(<field>) BY <field> and | timechart <stats-function>(<field>) BY <field>
The span option for timechart: you must know it defines the time bucket width (e.g., span=1h, span=5m).
The limit option: limits the number of series (columns) in the output. Default is 10.
The useother option: when set to t (true), groups less frequent values into 'Other'. Default is t.
The usenull option: when set to t, includes a column for null values. Default is t.
The partial option for timechart: when set to f, excludes the first and last bucket if they are partial. Default is t.
The difference between over and by: over designates the x-axis field, by designates the series.
Common traps the exam sets:
Trap: A question shows a chart command without span and asks why the chart looks odd. The correct answer is 'Because timechart requires span, not chart.' But chart does not have a span option — only timechart does.
Trap: The exam says 'Which option would you use to hide time buckets with no events?' The correct answer is usenull=f. Beginners often pick useother=f because they confuse the two.
Trap: The exam presents a scenario with 50 distinct values and asks why the chart is cluttered. The correct answer is 'Use limit=10' — not 'Use useother=t', because useother groups the rest, but without limit, the chart still has 50 series if useother is f.
Trap: The exam asks 'Which command makes the x-axis time-based?' The correct answer is timechart, not chart. A chart command with _time is possible but inefficient.
Trap: The exam shows | chart count by host | and asks 'What does the chart look like?' The correct answer: a bar chart with one bar per host, count on the y-axis.
Formatting options that are easy to confuse:
useother affects whether low-frequency values are lumped into 'Other'.
usenull affects whether null values get their own column.
partial only applies to timechart and controls partial time buckets.
limit controls series count.
The exam also tests that chart and timechart are transforming commands, meaning they end a search pipeline — you cannot pipe chart into chart. The correct pattern is search commands first (like where, eval, rex), then chart or timechart.
Exact concept names to memorise:
'Bucket span' — the time interval for timechart.
'Series' — the columns created by the by clause.
'Aggregation function' — count, sum, avg, min, max, distinct_count, values, first, last.
'Multi-series chart' — a chart with more than one series (more than one bar/line colour).
'Single-series chart' — a chart with only one series (all bars same colour).
The exam may also present a multiple-choice question that shows a partial JSON or XML configuration snippet for a chart in Splunk dashboards. However, for SPLK-1003, the focus is on the SPL (Search Processing Language) commands, not dashboard XML. Stick to the SPL syntax.
Use `chart` when you want to group data by any field (like host or status) and show an aggregate value for each group.
Use `timechart` when you specifically want to see how a metric changes over time, using `_time` as the grouping field with automatic time buckets.
The `span` option on `timechart` defines the width of each time bucket; choose it based on how much data you have and what pattern you expect to see.
The `limit` option controls how many distinct series (columns) appear in the chart output to prevent clutter and improve rendering speed.
The `useother` option lumps low-frequency values into a single 'Other' series, while `usenull` controls whether null values get their own column.
Remember that `chart` and `timechart` are transforming commands that end the search pipeline — place them after all filtering and calculation commands.
A chart created with `chart` uses the `by` field for series and the `over` field for the x-axis; in `timechart`, the x-axis is always `_time`.
These come up on the exam all the time. Here's how to tell them apart.
Chart Command
Groups data by any field you specify with `over` and `by`.
Does not have a `span` option; grouping is by distinct field values.
Best used for comparing categories or hosts, not time trends.
Timechart Command
Automatically groups data by `_time` into time buckets.
Has a `span` option to control the width of each time bucket.
Best used for showing how a metric changes over time.
useother=t
Groups low-frequency values into a single 'Other' series.
Reduces chart clutter by hiding many tiny series.
Default behaviour in chart and timechart.
useother=f
Does not group low-frequency values; every value gets its own column.
Can produce charts with many series, potentially cluttered.
Useful when you need to see every distinct value individually.
usenull=t (default)
Includes a column for null values where the grouped field is missing.
Shows time buckets with zero events in timechart as a separate line.
Can create extra lines in multi-series charts for null data.
usenull=f
Excludes the null column entirely from the output.
Removes time buckets with zero events, creating a continuous line.
Useful when null is not a meaningful category.
limit=N (e.g., limit=5)
Shows only the top N distinct values for the `by` field.
Reduces the number of series in the chart significantly.
Often combined with `useother=t` to group the rest.
No limit (default 10)
Shows up to 10 distinct values by default (can be changed).
May produce a cluttered chart if there are many distinct values.
Without limit, the output includes all values, which can overwhelm the visualisation.
Mistake
The `chart` command can only produce bar charts.
Correct
The `chart` command produces a table of data that can be displayed as a bar chart, column chart, line chart, pie chart, area chart, or scatter plot depending on the visualisation you select in the UI. The command itself does not determine the chart type.
Beginners see the default visualisation in Splunk's UI (often a bar chart) and assume chart=bar. They don't realise the output is a table first, and the visualisation type is a separate choice.
Mistake
`timechart span=1h count by host` will show one line per host that appears at least once in the entire search time range.
Correct
`timechart span=1h count by host` will show a line for every host that appears in any time bucket, but hosts that have no events in a specific bucket will still appear as a zero value if `usenull=t` (default), or the line will be interrupted if `usenull=f`. The line is continuous only for hosts that have events in every bucket.
People think 'by host' means 'a line for each host that exists', but Splunk dynamically creates series only for values that appear in the data. A host that only appears once in the 24-hour range will still get a line, but it will be a line with zeroes for the other 23 hours — often invisible. This leads to confusion when the chart seems to have fewer lines than expected.
Mistake
The `limit` option in `chart` limits the number of rows in the output table.
Correct
The `limit` option limits the number of distinct values for the field after `by` (the series), not the number of rows. For `chart count by host limit=5`, you get up to 5 columns (hosts) in the output, but the number of rows is determined by the `over` field.
Beginners confuse 'limit' in chart with 'limit' in the search command (which limits the number of events). The chart command's limit is about series cardinality, not event count.
Mistake
You can use `chart` to compute a running total or cumulative sum over time.
Correct
`chart` does not compute running totals. It groups events into buckets and aggregates within each bucket independently. For a running total, you need the `eventstats` or `streamstats` command with the `sum` function, then `chart` to visualise.
People think 'chart over time' implies a cumulative view, but chart is per-bucket, not cumulative. This misconception leads to incorrect data interpretation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`chart` groups data by any field you specify using the `over` clause, while `timechart` automatically groups data by `_time` into time buckets. `timechart` has a `span` option to control bucket width; `chart` does not use `span`.
Gaps appear when there are time buckets with zero events that match your search. To make the line continuous across those gaps, add `usenull=f` to your timechart command. This removes the empty buckets from the output, connecting the line.
Use the `limit` option, e.g., `| chart count by host limit=10`. This shows only the top 10 hosts. The other hosts are either grouped into 'Other' (if `useother=t`, the default) or omitted entirely (if `useother=f`).
`useother=t` (the default) collects all values that are not in the top N (as set by `limit`) and groups them into a single series called 'Other'. `useother=f` removes those values entirely, so you see only the top N values with no summary.
Yes. If you omit the `by` clause, `chart` returns a single aggregate value. For example, `| chart count` returns one number: the total event count. But that is not useful for a chart — it is just a number. You almost always need a `by` or `over` to create meaningful axes.
The last time bucket might be partial (e.g., if the current hour is only 10 minutes old). The partial bucket has a lower denominator, so the count appears artificially low or high. Use `partial=f` to hide partial buckets at the edges of the time range.
You've finished Chart Commands and Formatting. Continue through the SPLK-1003 study guide to build a complete picture of the exam.
Done with this chapter?