3.7 Controlling Search Jobs

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

3.7 Controlling Search Jobs

Key Takeaways Explain This Topic AI

Each Splunk search creates a job with a status such as Running, Paused, Finalized, Done, or Failed that you manage from the Job menu.

Pause suspends work resumably; finalize stops early but keeps intermediate results; stop/cancel aborts and discards the in-progress result cache.

Ad hoc jobs expire after a default lifetime of about 10 minutes unless you extend lifetime or share/save; sharing often lengthens availability (commonly toward 7 days).

The Job Inspector surfaces execution costs and job properties so you can diagnose slow or unexpected searches at User level.

Last updated: August 2026

3.7 Controlling Search Jobs

Quick Summary: Every search you run creates a search job with a status, a lifetime (TTL) , and controls to pause , stop/cancel , or finalize execution. The Job menu, Job Inspector , and share/lifetime settings are Core User essentials for blueprint topic 2.7 Control a search job .

When the search button spins, Splunk is not only “thinking”—it is managing a discrete job artifact: intermediate results, timeline buckets, and metadata. User-level competency means knowing how to pause expensive work, keep partial results with finalize, inspect why a search is slow, and share a job long enough for a teammate to open it.

What Is a Search Job?

A job is the system object created when you:

Run an ad hoc search in the Search app,
Open a report,
Load a dashboard panel that executes a search,

Or otherwise dispatch a search that produces results.

Ad hoc searches are the primary focus for topic 2.7. The job has:

A search ID (SID) ,
A dispatch state / status ,
Result artifacts stored for a limited lifetime ,

Optional permissions when shared.

Status Concept Meaning Typical User Action
Running Job is actively executing Wait, pause, finalize, or stop
Paused Execution suspended; can resume Resume or finalize
Finalizing / Finalized Stopping with intermediate results retained Inspect partial results
Done Completed successfully Export, save as report, share
Failed Fatal error (for example, invalid syntax) Fix SPL and rerun
The Job Menu: Pause, Stop, and Finalize

While a search is running—or after it is paused/finalized—open the Job menu on the Search page.

Pause

Temporarily suspends execution.

Useful when a search is taking too long and you need to think, adjust strategy, or free attention without discarding progress.

You can resume (unpause) later from the job controls.

Stop / Cancel

Stops the job and typically discards the in-progress result cache (cancel semantics).

Use when the search is clearly wrong (bad filter, accidental All time on a huge index) and you do not need partial output.

After cancel, rerun a corrected, narrower search.

Finalize

Stops the search but keeps intermediate results available through the results interfaces.

Ideal when you already see enough events/statistics to answer the question and do not want to wait for full completion.

Distinct from cancel: finalize preserves usable partial output; cancel throws the work away. Decision tree (User level):

Need a break but might continue? → Pause
Query is wrong; discard work? → Stop/Cancel
Enough partial results to proceed? → Finalize
Finished naturally? → Done → export/share/save

Warning

Finalize is not the same as Save As Report. Finalize only ends the current job early with partial artifacts. Saving creates a reusable search definition (covered in 3.8 / domain 6).

Job Settings, Sharing, and TTL (Lifetime)
Default Lifetime

When you run a new search, Splunk retains the job for a default lifetime of 10 minutes (commonly described as the job TTL). After expiration, artifacts are cleaned up and the results link stops working unless the lifetime was extended.

Edit Job Settings

From Job → Edit Job Settings you can adjust:

Read permissions — default Private (only you).

Lifetime — keep the job available longer than the default window.

Share Job Basics (User Level)

Sharing a job is handy when a colleague must see the exact result set you produced:

Use Share / share-link workflows from search actions.

Sharing commonly extends lifetime (often to 7 days when the job is saved/shared in the standard UI pattern) and can set broader read access (for example, Everyone) depending on the dialog choices and your capabilities.

Sharing a job shares that run’s artifacts—not automatically a permanently scheduled report.

Action Keeps SPL for reuse? Keeps this run’s artifacts? Typical Lifetime Effect
Do nothing No Until default TTL (~10 min) Expires quickly
Share / extend lifetime No (unless also saved) Yes, longer Often days (for example, 7)
Save As Report Yes Separate from ad hoc TTL Report can be rerun anytime
Export CSV/JSON No Local file copy Independent of job TTL

Touching/viewing jobs can refresh activity in some deployments; still treat TTL as real—export or save if you need durability.

Job Inspector Introduction

The Search Job Inspector opens from the Job menu ( Inspect Job ) or from Activity → Jobs management views. At User level, you are not expected to tune limits.conf ; you are expected to know the Inspector exists and what questions it answers:

How long did the job run?

How many events were scanned vs returned?

Which command phases cost the most?

Did the job fail, pause, or finalize?

What were key search job properties?

Use the Inspector when:

A search feels unexpectedly slow,
Result counts look wrong relative to the timeline,
You need evidence that a finalize left partial results,

You are validating that time bounds and filters behaved as intended.

The Inspector is a diagnostic readout , not a replacement for writing efficient searches (narrow time, specific index/sourcetype, precise fields).

Job Management Page Awareness

From the Splunk bar, Activity → Jobs opens the job management list of recent jobs. User-level expectations:

Find your recent ad hoc jobs by SID, search string, or status.

Reopen results before TTL expiry.

Inspect or manage jobs you own.

Understand that managing other users’ jobs typically requires admin-equivalent capabilities—beyond ordinary User exam depth.

Practical Control Scenarios
Scenario A — Accidental All Time

You start error OR fail OR fatal over All time on a busy index. Timeline starts filling for months of data.

Correct move: Stop/Cancel, set Last 24 hours, add index= and sourcetype= , rerun.

Scenario B — Spike Already Visible

A 15-minute search is 40% complete but the timeline already shows a clear spike you zoomed into.

Correct move: Finalize, investigate events, optionally export the partial set.

Scenario C — Hand Off to a Teammate

Your Done job proves a vendor outage window.

Correct move: Share the job / extend lifetime so the teammate can open the same artifacts; also Save As Report if they must rerun tomorrow.

Scenario D — Performance Mystery

Same SPL is fast one day and slow the next.

Correct move: Open Job Inspector, compare scanned events, time range, and costly phases before rewriting everything.

Exam Distinctions to Memorize

Pause = temporary hold; resumable.

Finalize = stop early; keep intermediate results.

Stop/Cancel = abort; discard the in-progress cache.

Default job lifetime ≈ 10 minutes ; sharing/saving extends durability for collaboration.

Job Inspector explains cost/properties; it does not by itself fix SPL.

These controls keep you efficient in the Search app and map cleanly to topic 2.7 without crossing into Power User knowledge-object design.