WLK — Workload Knowledge¶

Workload Knowledge tracks the execution health of your scheduled searches — are they running on schedule, completing without errors, not skipping, and not quietly costing more than they should? It turns Splunk’s own scheduler activity into tracked, scored entities.

Note

WLK is a licensed / restricted component.

WLK entities table, scheduled searches grouped by app with their execution KPIs

A WLK scheduled-search entity overview with skip ratio, errors, and SVC cost

What WLK tracks¶

Each entity is one scheduled search in one context — its app, owner, and saved-search name together. The state is driven by these anomaly reasons:

Anomaly	Meaning
Skipping searches	The scheduler is skipping runs. Orange below 5%, red at or above 5% by default.
Execution errors	The scheduler reported execution errors.
Execution delayed	The search has not run on its cron schedule (within a grace period).
Orphan search	The search’s owner is no longer valid, so it cannot run.
Runtime / cost outliers	An ML-detected spike in run time or cost.
Versioning drift	The search definition changed.
App disabled	The parent app is disabled, so its scheduled searches do not run.

The KPIs behind these include execution / completed / skipped / error counts, run time (elapsed), CPU and memory percentages, scan count, and — on Splunk Cloud — SVC consumption per search, for cost visibility.

Versioning¶

WLK can fingerprint each saved search’s definition and flag when it changes — recording a versioning event and, when the change was made through Splunk Web or the API, a diff plus who changed it and when. This is invaluable for correlating a sudden jump in run time, cost, or skip rate with an edit to the search. Versioning is opt-in per app.

The tenant default threshold¶

WLK has a special tenant-wide fallback: a default threshold row that applies to any entity without its own per-entity threshold, so you can set sensible limits once and override only where needed.

Setup notes¶

The creation wizard auto-builds the trackers it needs (scheduler, metadata, orphan, introspection, and — on Splunk Cloud — SVC).
Entities are grouped by app, or by a custom overgroup if you want to host several search-head tiers in one tenant.
On Splunk Cloud, point WLK at a remote deployment targeting the relevant search-head tier (see Integrations & Remote Deployments).

Tip

Dedicate a Workload tenant per search-head tier, and use an overgroup only when you deliberately want to combine tiers. Outlier detection is not recommended for the scheduler counters (too discrete), but it is useful for run-time and cost trends.