Transactions Advanced Options

In Splunk, a transaction is a way of grouping related events together into a single logical unit. Think of it like stitching together separate snapshots to make a movie. By default, when you write something like ... | transaction user_id, Splunk finds events that share the same user_id field and bundles them together. But the default behaviour has a critical limitation: it uses a default 120-second pause (no event arrives for 120 seconds) to decide when to close a transaction. This works poorly for slow processes.

The three advanced options — maxspan, maxpause, and keepevicted — give you precise control over how transactions start, continue, and end. Let's break them down.

maxspan defines the absolute maximum total time a single transaction can cover, from its very first event to its very last event. If maxspan=10m, any transaction that starts and has not ended after 10 minutes is forcibly closed at the 10-minute mark. This prevents a single transaction from running forever if events trickle in slowly. For example, if you are tracking a user's shopping cart session, you know a real session never lasts longer than 1 hour — setting maxspan=1h cuts off any transaction that tries to exceed that.

maxpause sets the maximum allowed time gap between consecutive events inside one transaction. If maxpause=5m, Splunk waits 5 minutes after the last event. If no new event arrives in that window, it closes the transaction. If a new event arrives before the pause expires, the clock resets. This is brilliant for grouping events that should be close together but could have occasional gaps. For example, a user clicking through pages on a website might pause for 3 minutes to read an article. A maxpause=10m would keep them in the same session.

keepevicted changes what happens to events that get kicked out of a transaction because of the time limits above. Without keepevicted, those orphaned events are discarded — they vanish from your result set. With keepevicted=true, Splunk outputs them as single-event transactions (a transaction containing just that one event). This is crucial for auditing. If you want to know which events were broken off (evicted), you can see them instead of wondering where data went.

Here is how they work together in a real Splunk search:

sourcetype=access_combined
| transaction clientip maxspan=30m maxpause=5m keepevicted=true

This tells Splunk: group events by clientip. Let any single transaction last at most 30 minutes. Wait up to 5 minutes between events before closing. And show me the events that got cut off as their own tiny transactions.

Why do you need these options? Without them:

In older Splunk versions, users had to chain multiple commands or use complex eval logic to approximate this behaviour. The transaction command with advanced options replaced all that workarounds. It is now the standard way to group events into meaningful sessions.

The important detail: these options only work inside the transaction command. They are not available in stats or eventstats. You must write ... | transaction [field] [options].

Finally, a nuance for the exam: maxspan is always measured from the timestamp of the *first* event. maxpause resets on each new event. keepevicted does not change the transaction logic itself — it only changes the output behaviour. Memorise that.

Imagine you work in IT support for an online retail company. Your boss says, 'Find every customer session where someone looked at a product, added it to the cart, and then abandoned the cart without checking out.' Your company's web server logs every page click, API call, and button press. Each event has a session_id field.

Without transactions, you would have thousands of individual events — clicks on product pages, AJAX calls to update the cart, abandonment events. You need to group them by session. Here is the step-by-step scenario:

Here is the actual search you use:

sourcetype=web_log
| transaction session_id maxspan=1h maxpause=10m keepevicted=true
| search duration>0
| stats count by status

This is exactly what senior Splunk administrators do daily. They do not just write transaction — they tune maxspan and maxpause based on business knowledge. For example, if you know a customer never spends more than 2 minutes on a checkout page, you set maxpause=2m to close transactions quickly. If you are tracking a multi-step API call that takes 10 seconds between steps, you set maxpause=30s to avoid splitting mid-call.

The key lesson: maxspan and maxpause are not random numbers. They come from understanding the process you are monitoring. A banking transfer might take seconds (maxpause=1m). A customer service ticket might take days (maxspan=48h). Always calibrate these values.