3.7 Controlling Search Jobs

Key Takeaways

  • 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 ConceptMeaningTypical User Action
RunningJob is actively executingWait, pause, finalize, or stop
PausedExecution suspended; can resumeResume or finalize
Finalizing / FinalizedStopping with intermediate results retainedInspect partial results
DoneCompleted successfullyExport, save as report, share
FailedFatal 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.
ActionKeeps SPL for reuse?Keeps this run’s artifacts?Typical Lifetime Effect
Do nothingNoUntil default TTL (~10 min)Expires quickly
Share / extend lifetimeNo (unless also saved)Yes, longerOften days (for example, 7)
Save As ReportYesSeparate from ad hoc TTLReport can be rerun anytime
Export CSV/JSONNoLocal file copyIndependent 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:

  1. A search feels unexpectedly slow,
  2. Result counts look wrong relative to the timeline,
  3. You need evidence that a finalize left partial results,
  4. 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

  1. Pause = temporary hold; resumable.
  2. Finalize = stop early; keep intermediate results.
  3. Stop/Cancel = abort; discard the in-progress cache.
  4. Default job lifetime ≈ 10 minutes; sharing/saving extends durability for collaboration.
  5. 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.

Test Your Knowledge

What is the key difference between finalizing a search job and canceling/stopping it?

A
B
C
D
Test Your Knowledge

What is the typical default lifetime of a newly run ad hoc search job if you do not extend or share it?

A
B
C
D
Test Your Knowledge

Which tool should you open to review search execution costs and detailed job properties?

A
B
C
D