TrackMe Use Cases — Organised by User Intent

How this page is organised

Each section answers a real-world question (“I want to know when…”, “I want to monitor…”, “I want to integrate with…”). For each goal we give you the shortest path from intent to action:

• which component(s) deliver the use case,

• whether it is out-of-the-box, configurable, or requires custom SPL,

• a pointer to a pre-built FLX template if one exists (see FLX (Flex Objects) Use Case Template Catalog for full details),

• and a cross-reference to the deeper admin / user / white-paper guide.

Cadence:

This page changes every time TrackMe grows new capabilities. Current snapshot: TrackMe v2.3.23.

I want to know when data stops flowing

The foundational TrackMe use case. The platform was built around this problem, and three of the six components answer different facets of it.

Detect when an (index, sourcetype) feed stops receiving data

Component(s):

DSM

Status:

Out-of-the-box. Auto-discovered by the DSM tracker.

How:

Each (index, sourcetype) becomes a DSM entity; the tracker measures ingestion delay, latency, and event count. Static or variable delay thresholds trip orange / red state.

Tuneables:

variable delay (time-of-day / day-of-week slots), lagging classes, adaptive delay (auto-recompute thresholds from history), priority / SLA / tag policies, monitoring-time policy.

See also:

Use Case Demo: This is All About Feeds, Impact scoring & thresholds, Impact scoring & thresholds, DSM — Data Source Monitoring.

Detect when a specific host stops sending data

Component(s):

DHM

Status:

Out-of-the-box. Hosts × sourcetypes are auto-discovered.

How:

One DHM entity per host × sourcetype combination (or per host alone in merged mode). 2.3.23+ adds the optional breakby_extra_fields knob for richer combos (e.g. include source).

Tuneables:

same as DSM (variable delay, lagging classes, adaptive delay, policies, monitoring-time).

See also:

Notes, Hybrid trackers.

Detect silent metric-sending hosts

Component(s):

MHM

Status:

Out-of-the-box. mstats-based discovery and tracking.

How:

One MHM entity per host × metric category. Detects when a host stops emitting metrics that it previously emitted.

Tuneables:

static delay thresholds, priority / SLA / tag policies. Variable delay and lagging classes are not supported on MHM.

See also:

Notes.

Detect silent CSV or KVstore lookup files

Component(s):

DSM in search_mode=lookups

Status:

Configurable. Requires the companion add-on TA-trackme-lookupmonitor installed on the SH.

How:

The hybrid-tracker wizard exposes a Lookups monitoring mode that turns every CSV file and KVstore collection into a DSM entity, with filesystem mtime and accurate row count.

Tuneables:

same as regular DSM (priority, SLA, …); thresholds apply on delay only — latency is neutralised because lookups have no _indextime.

See also:

Lookup monitoring, QUICK START - Design and automate through lookup knowledge.

Detect event drop-outs at the index level (independent of host / sourcetype)

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_detect_drop_events_count_absolute (hourly window), splk_detect_drop_events_count_rolling (rolling 5-minute), and splk_hosts_tracking (per-host).

How:

Computes per-index event count and distinct host count, with native ML outlier detection on the volume so abnormal day-over-day drops are surfaced even if the static threshold would not have caught them.

See also:

Use TrackMe to detect abnormal events count drop in Splunk feeds.

Detect routing or parsing misconfiguration (events in lastchanceindex)

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_lastchanceindex.

How:

Watches the lastchanceindex for any traffic; non-zero counts are a strong signal that a pipeline misroutes events.

I want to monitor Splunk platform health (the full stack)

TrackMe ships an opinionated set of FLX templates that cover the most common “is Splunk itself healthy?” questions. All of them run as scheduled FLX entities and participate in TrackMe’s stateful alerting, ACK system, smart status, AI Assistant and impact scoring.

Indexer cluster status (Splunk Enterprise)

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_splunk_enterprise_cluster_status (global — availability, peers up / down / unknown), splk_splunk_enterprise_cluster_peers_status (per-peer — bucket %, primary %, balancing deviation, plus introspection CPU / mem join).

See also:

Monitor Splunk Indexer Clusters.

Search-head cluster status

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_splunk_shc_global_status (captain-level flags: maintenance mode, min_peers_joined, rolling_restart, service_ready, kvstore_maintenance), splk_splunk_shc_members_status (per-member lost / down / pending).

Dependency:

A TrackMe remote account targeting any SHC member is required for both templates.

See also:

Monitor Splunk Search Head Clusters, Remote Splunk deployments.

Bucket health (timestamp parsing, premature rolls, quarantine)

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_bucket_health_per_index — every 30 min, | dbinspect-based; surfaces premature small buckets and quarantined buckets, both classic timestamp-parsing failure symptoms.

Knowledge-bundle size on the SH tier

Component(s):

FLX

Status:

Pre-built FLX template (with third-party dependency).

Templates:

splk_bundle_size. Requires the Splunkbase app sa-littlehelper (#6368) which provides | bundlefiles.

Why it matters:

bloated bundles silently slow search dispatch across the entire SH tier.

KV-store readiness and per-collection size

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_kvstore_status (service readiness — alerts when KV goes degraded / down), splk_kvstore_size (per-collection vs total size with thresholding).

Pipeline queue saturation

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_queues_filling — parsing / aggregator / typing / indexer queue fill metrics. The canonical backpressure indicator meaning the indexer tier needs more horsepower or the input is ingesting too fast.

Parsing issues (LineBreaking / Aggregator / DateParser)

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_parsing_issues_per_component — hourly aggregation of WARN / ERROR from the canonical bad-props.conf symptom signatures.

Data Model Acceleration (DMA) completeness

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_dma — complete %, size, run duration, bucket count with ML outlier detection. Surfaces stuck or under-performing accelerations.

HEC ingestion errors

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_splunk_hec_errors — parsing-error breakdown by parsing_err, with source-IP dcount to localise blame.

Universal Forwarder fleet version compliance and dropout

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_uf_clients_versions_tracking (UF version compliance — picks highest version as target, alerts on % non-compliant), splk_deployment_server_clients (silent UF dropout — alerts on missing phone-home).

Search-head workload and scheduler health

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_search_head_activity (dispatched, eligible, lag, runtime, scheduler cycles, with ML outliers), splk_search_head_healthmon_artifact_count_remote (per-SHC-member response time and artifact count via remote search).

See also:

Monitor Splunk Workload with TrackMe’s Workload component.

Per-instance CPU and memory consumption

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_splunk_infra_cpu_used, splk_splunk_infra_mem_used — Splunk-introspection-based per-instance avg / p95 / max.

Distinction:

Use these for the Splunk process view. For the host OS view of the underlying servers, use the ta_nix_* and ta_windows_* templates (see the host OS section below).

Log-level variations (catch error storms early)

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_splunk_infra_log_level_variations — counts INFO / WARN / ERROR / FATAL across the Splunk infra with ML outliers for trend deviation.

See also:

Analyse log messages logging level to detect behaviour anomalies using TrackMe’s Flex Object and Machine Learning Anomaly Detection.

DB Connect modular-input health

Component(s):

FLX

Status:

Pre-built FLX template (with dependency).

Templates:

splk_dbconnect. Requires Splunk DB Connect.

I want to monitor cost and license consumption

Licensing is one of the most heavily templated areas of the FLX library — six dedicated templates plus the daily-variation pair, covering both Splunk Enterprise and Splunk Cloud.

Splunk Enterprise license pool consumption

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_license_pool_usage (per-pool % used + GB used, with ML outliers), splk_license_usage_global_splunkenterprise (rolling 60 min / 4 h / 24 h — designed for near-real-time anomaly detection), splk_license_usage_per_index_splunkenterprise (same but per-index to pinpoint a spike).

Splunk Cloud license, storage and SVC consumption

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_license_usage_global_splunkcloud, splk_license_usage_per_index_splunkcloud, splk_splunk_cloud_storage_usage (storage vs licensed), splk_splunk_cloud_svc_usage (overall SVC usage % with outliers), splk_splunk_cloud_svc_usage_by_app (per-app SVC attribution), splk_splunk_cloud_svc_usage_by_consumer_service (per-consumer attribution).

See also:

Tracking Splunk Cloud SVC consumption in TrackMe.

Daily variation detection on global / per-index volume

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_detect_daily_variations_volume_global, splk_detect_daily_variations_volume_index, splk_volume_ingested_per_day. All ML-outlier-enabled and scheduled in the 03:05 — 04:15 UTC quiet hours.

Detect oversized lookup files before they hurt bundle replication

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_large_lookup_files — every 12 hours via /services/data/transforms/lookups, with ML outliers on total lookup size.

I want to monitor scheduled-search execution health

The WLK (WorkLoad Knowledge) component is purpose-built for this and includes signals you cannot get from FLX alone.

Detect scheduled searches that skip, error, or run long

Component(s):

WLK

Status:

Out-of-the-box. Auto-discovered.

How:

Every scheduled search becomes a WLK entity with skip rate, error count, execution-time metrics. Dynamic thresholds support a tenant-default fallback row (object_id == "default") so you can manage the whole tenant’s thresholds from one record and override per entity as needed.

See also:

WLK — Workload Knowledge, WLK — Workload Knowledge, Monitor Splunk Workload with TrackMe’s Workload component.

Detect silently broken scheduled searches

Component(s):

WLK

Status:

Out-of-the-box. Three WLK-only signals fire here.

How:

orphan (owner user no longer exists), app enablement (parent app disabled — search no longer dispatches), versioning (savedsearch definition has changed since the fingerprint was taken, surfacing unannounced edits).

Audit “all-time” or user-owned scheduled searches (good-practice violations)

Component(s):

FLX

Status:

Pre-built FLX templates.

Templates:

splk_good_practices_alltime_scheduled (enabled scheduled searches with - / all time earliest — a notorious cost driver), splk_good_practices_run_as_user_scheduled (scheduled searches running as a named user — offboarding fragility), splk_good_practices_detect_dynamic_sourcetype (dynamic / numerically suffixed sourcetypes that bloat metadata).

I want to monitor field-parsing quality and CIM compliance

This is the dedicated remit of the FQM component.

Track field coverage and parsing success per dataset

Component(s):

FQM

Status:

Out-of-the-box (with custom templates per CIM data-model).

How:

FQM defines field-quality checks per (source, sourcetype, host), producing percentage_passed / percentage_failed and per-field counts. CIM-aware templates ship in the FQM wizard so common data models (Authentication, Network_Traffic, Web, …) can be onboarded quickly.

Tuneables:

priority, SLA, tag policies, monitoring-time policy, dynamic thresholds per metric.

See also:

Use Case Demo: Fields Quality (CIM and non-CIM).

Aggregate FQM outcomes into a single FLX-tracked health metric

Component(s):

FLX

Status:

Pre-built FLX template.

Templates:

splk_splunk_fields_quality — aggregates the FQM check outcomes into per-(source, sourcetype, host) % passed / % failed and applies ML outliers for drift detection. Useful when you want one aggregate view next to your other FLX entities.

I want to detect anomalies without writing thresholds by hand

Native ML outlier detection (DensityFunction)

Component(s):

DSM, FLX recommended; DHM selective; MHM / FQM / WLK not recommended.

Status:

Configurable. Enabled per tenant via vtenant_account.mloutliers_<component>.

How:

TrackMe trains a per-entity, per-metric DensityFunction model (Gaussian KDE / Normal / Exponential / Beta) with optional seasonality (hour-of-day, day-of-week, dow × hod). Low-confidence predictions are suppressed so a half-trained model does not page the operator.

Pre-wired templates:

20 of the 65 FLX templates ship with outliers_metrics already declared — license / volume, Cribl traffic, SOAR runtime, SH activity, parsing-quality drift, etc. See the Outlier-friendly? column in FLX (Flex Objects) Use Case Template Catalog.

See also:

Outlier detection.

Custom per-entity SPL checks (hybrid trackers)

Component(s):

all six (DSM, DHM, MHM, FLX, FQM, WLK)

Status:

Configurable. Enterprise edition caps at 8 hybrid trackers per tenant; Foundation rejects; Unlimited is uncapped.

How:

Per entity, configure a custom SPL check that contributes score / state / anomaly_reason / enrichment to the entity’s final state. Useful when the default component logic cannot reach the data, or when you need a domain-specific check on top of the built-in tracker.

See also:

Hybrid trackers.

I want to monitor anything I can express as SPL

Use a pre-built FLX template

Component(s):

FLX

Status:

Out-of-the-box. Sixty-five templates ship in the catalog.

How:

The Virtual Tenants FLX wizard guides you through picking a template by category, customising replacements (index name, …), and creating the saved search. The full catalog lives at FLX (Flex Objects) Use Case Template Catalog.

Author a custom FLX use case

Component(s):

FLX

Status:

Configurable. Available in every edition that includes FLX.

How:

The wizard accepts arbitrary SPL that must produce rows with object, status, status_description, metrics (JSON dict), optionally outliers_metrics (JSON dict), and optionally max_sec_inactive for inactivity alerting. The SPL becomes a saved search; the rows become FLX entities; thresholds / outliers / policies apply.

See also:

FLX — Flex Objects, Flex Objects - Adapt TrackMe to any monitoring use case (splk-flx).

Apply time-aware thresholds to an FLX KPI (business hours vs nights)

Component(s):

FLX

Status:

Configurable.

How:

FLX dynamic thresholds support a variable mode with day-of-week × hour-of-day slots. Each slot carries its own threshold value, so a metric can be alerted on at one level during business hours and another at night.

I want to be alerted intelligently (and only when it matters)

This section enumerates the noise-reduction and prioritisation features that turn raw state transitions into actionable signal.

Prioritise entities so the right alerts get the right urgency

Capability:

Priority policies (regex, lookup, SPL search).

How:

Policies automatically assign priority (low / medium / high / critical / pending) to entities by name pattern, lookup membership, or live SPL match. Manual overrides always win.

See also:

Priority, Priority.

Bucket entities into SLA classes (platinum / gold / silver / custom)

Capability:

SLA policies + trackme_settings.conf [sla].

How:

SLA classes are tenant- or system-defined with their own uptime targets and reporting windows. SLA policies apply them automatically across entities. Maintenance windows and bank holidays are excluded from SLA timers when configured.

See also:

Using SLA alerting to build a 2-tier monitoring system, Maintenance mode, Bank holidays.

Tag entities for routing and grouping

Capability:

Tag policies (union semantics — multiple matches accumulate).

How:

Regex / lookup / SPL policies assign one or more free-form tags to entities — used for filtering in the UI, downstream search, and alerting rules.

See also:

Tags.

Demote false positives — disruption queue (grace period)

Capability:

Disruption queue.

How:

An entity that goes red is held in blue state until it has been continuously red for disruption_min_time_sec. Any green tick resets the timer. Configured at tenant default and per-entity override.

See also:

Disruption queue, The entity state machine.

Don’t alert when a cluster is mostly healthy — logical groups

Capability:

Logical groups.

How:

Cluster N entities (cross-component supported); while green % stays above object_group_min_green_percent, struggling members are demoted to blue (“protected by the group”). When too many members are red, all members surface as red so the underlying cluster issue gets escalated.

See also:

Logical groups.

Mute outside business hours — monitoring-time policy

Capability:

Monitoring-time policy.

How:

Per-tenant (and per-entity override) day-of-week × hour-of-day window outside which the entity is forced orange (paused). Useful when feeds legitimately stop overnight or on weekends.

Tighter thresholds during business hours — variable delay

Capability:

Variable delay (DSM / DHM only).

How:

Day-of-week × hour-of-day delay-threshold matrix. Tight thresholds during the business day, looser at night, looser still on weekends. The system falls back to the static threshold for any uncovered slot.

Recompute thresholds from history — adaptive delay

Capability:

Adaptive delay (DSM / DHM only).

How:

Persistently-red delay_threshold_breached entities have their thresholds automatically recomputed from the last 30 days of metrics. 24-hour cool-off prevents oscillation. Opt-in via allow_adaptive_delay on the entity. Since 2.3.23, the adaptive path also recomputes individual variable-delay slot thresholds.

Acknowledge known issues — sticky and unsticky ACK

Capability:

Acknowledgments.

How:

An ACK silences notifications without hiding the entity’s real state. Sticky ACKs require manual close; unsticky ACKs auto-expire after ack_period (default 24 h). Reason-change revocation can be enabled so the ACK is removed if the underlying anomaly reason changes.

See also:

Acknowledgments.

Auto-acknowledge entities on alert fire

Capability:

Auto-ack alert action.

How:

Triggered from any saved search firing; acks all returned entities sticky / unsticky with a configurable duration and comment. Useful for maintenance windows known upstream, or to short-circuit known-noisy periods.

Embed the right context in the alert email

Capability:

Stateful alerting email + embedded 24h charts + AI status reports.

How:

One email per state transition (open / update / close), correctly threaded via In-Reply-To. Optional SVG → PNG 24-hour charts embedded inline. Optional LLM-generated 2 – 3 paragraph AI investigation summary embedded in the body, with full entity context (priority, recent ACK history, active Guardian alerts, etc.).

See also:

Stateful alerting, AI Assistant.

Exclude maintenance windows and bank holidays from SLA timers

Capability:

Maintenance KDB + bank holidays.

How:

The Maintenance KDB records planned and unplanned windows scoped to global / tenant / component / single-entity. SLA accounting and the monitoring-time policy both honour active windows. Bank holidays (40+ countries pre-seeded; recurring fixed / floating / custom rules) are tenant-opt-in.

See also:

Maintenance mode, Bank holidays.

I want to investigate and resolve fast when alerts fire

Trigger automated investigations — Smart Status

Capability:

Smart Status investigations.

How:

Triggered by the trackme_smart_status alert action. Generates component-specific investigation SPL (delay / future data / latency issues for DSM/DHM; skip / error / orphan for WLK; outliers and inactivity for FLX). Throttled to max 1 / 24 h per entity. Detects abnormal state-flipping patterns (high variance of flip count). Results indexed to trackme_summary for review in the Tenant Home modal.

See also:

Status flapping, The entity state machine.

Ask the AI Assistant in plain English

Capability:

AI Assistant chat (10 contexts).

How:

Per-page chat widget that knows the page’s context — Virtual Tenants, Tenant Home, single entity, REST API Reference, Backup & Restore, Maintenance Mode, Maintenance KDB, Bank Holidays, License Management. Per-entity context includes the entity’s current state, policies, recent ACK history, active Guardian alerts. Supports OpenAI, Azure OpenAI, Anthropic, Google Vertex, Mistral, Ollama, and Splunk Hosted. Optional anonymisation of entity / index names via SHA-256 hashing before LLM submission.

See also:

AI Assistant.

Hand off context to the next operator — notes and labels

Capability:

Notes (Markdown annotations) + labels (catalog-backed coloured chips).

How:

Notes are free-form Markdown attached to an entity with an audit trail (immutable — delete + recreate to edit). Labels are curated, colour-coded, multi-select chips defined once per tenant. Eight default labels are seeded on tenant creation. Use labels for lifecycle workflow (under-review → in-progress → resolved) and notes for narrative context (“re-deploy at 03:00 on 2026-05-08, root cause INC-12345”).

Generate notable events for Splunk ES correlation

Capability:

Notable event alert action.

How:

Triggered by the trackme_notable alert action. One event per firing of the saved search to a notable index (default trackme_notable), with drilldown links back into the TrackMe UI.

See also:

Notable events.

I want to monitor non-Splunk systems

This is where the companion add-ons unlock TrackMe beyond Splunk itself. See TrackMe Ecosystem — Companion Add-ons for the full inventory.

Monitor Cribl Stream pipelines, routes, packs, destinations

Component(s):

FLX

Status:

Pre-built FLX templates (10 templates).

Templates:

cribl_logstream_health_inputs, _health_outputs, _hosts_cpu_usage, _output_destination_pressure, _pack_traffic, _pipeline, _route_traffic, _total_traffic_inputs, _total_traffic_outputs, plus cribl_edge_fleet_metrics.

Dependency:

Cribl-shipped internal metrics indexed in Splunk (any Splunk_TA_cribl-equivalent setup).

See also:

Cribl monitoring, Cribl Stream & Edge API.

Monitor Cribl Edge node heartbeats via the Cribl API

Component(s):

FLX

Status:

Pre-built FLX template (with companion-TA dependency).

Templates:

cribl_edge_fleet_api — the only template that hard-depends on TA-trackme-cribl (uses | cribl).

Monitor Google SecOps (Chronicle) log-feed ingestion

Component(s):

FLX or hybrid trackers, custom-built.

Status:

Custom SPL via the | secops command provided by TA-trackme-google-secops.

How:

UDM-search-based entities, one per metadata.log_type, tracking event count and last-seen. Effectively extends DSM-equivalent monitoring to data living in Chronicle.

Important:

This add-on has a hard licensing dependency on trackme-app — the | secops command refuses to run without a valid TrackMe license.

Monitor Splunk SOAR (Phantom) deployment health

Component(s):

FLX

Status:

Pre-built FLX templates (9 templates).

Templates:

splk_soar_actions_adhocs_failures, _actions_playbooks_failures, _assets_health, _automation_brokers_manage, _concurrent_playbooks, _forwarding_splunk, _infra_load, _infra_memory, _services_health.

Dependency:

Splunk App for SOAR integration on the SH; SOAR-to-Splunk forwarding for the data-side templates.

See also:

Splunk SOAR, TrackMe App on SOAR.

Monitor Linux and Windows host CPU / memory

Component(s):

FLX

Status:

Pre-built FLX templates (4 templates).

Templates:

ta_nix_cpu_usage and ta_nix_mem_usage (require TA-nix), ta_windows_cpu_usage and ta_windows_mem_usage (require Splunk_TA_windows). Per-host avg / max / p95.

Aggregate a remote regional TrackMe into a central pane

Component(s):

all six (DSM, DHM, MHM, FLX, FQM, WLK)

Status:

Configurable. Replica trackers.

How:

One-way replication of a source TrackMe’s entity set into a local tenant. The local decision maker does not re-evaluate replicated entities — the source’s state is trusted, by design. Useful for a global SOC with regional TrackMe instances.

I want to operate at scale across multiple tenants / customers

This section enumerates the multi-tenancy, automation, and resilience features that make TrackMe deployable as a managed service or a multi-business-unit platform.

Isolate by tenant — Virtual Tenants

Capability:

Virtual Tenants.

How:

Each tenant has its own KV collections (suffixed _tenant_{tenant_id}), RBAC role triplet (admin / power / user), default thresholds, index scoping, scheduling, and an optional tenant_account to target a remote Splunk deployment instead of the local one. Configuration lives in a vtenant_account JSON object on the tenant record.

See also:

Creating a tenant, Managing tenants.

Aggregate across tenants without new infrastructure — Virtual Groups

Capability:

Virtual Groups.

How:

Read-only UI cards aggregating entities from N tenants (and N components per tenant), optionally filtered by priority. RBAC-controlled visibility. Useful for cross-tenant cards like “all high-priority entities in finance across three regions”. Virtual Groups do not participate in decision maker / alerting / scoring — they are pure read-only aggregation views.

See also:

QUICK START - Cross-tenant domain views with Virtual Groups.

Monitor any number of remote Splunk deployments

Capability:

Remote Splunk accounts.

How:

Per-account HTTPS URL, bearer token (encrypted, auto-rotated every N days), per-account RBAC role restrictions, multiple URLs per account for HA / DR with automatic failover. Per-tenant tenant_account selector points the tenant at local or any configured remote.

Edition gate:

Foundation does not support remote deployments.

See also:

Remote Splunk deployments.

Detect admin misconfiguration automatically — Configuration Guardian

Capability:

Configuration Guardian.

How:

Continuous background scan of common misconfiguration patterns, each emitting a structured alert with recommended_actions an admin (or the AI Assistant) can act on. Eight checks ship in v2.3.23: capability gaps on the tenant owner, missing indexes, remote-account token expiry, remote-account connectivity, AI-provider reachability, stale backups, incomplete backup runs, dead health tracker. Two severity tiers (warning / critical); per-tenant and system-wide scopes; full audit trail in index=trackme_audit sourcetype=trackme:audit:guardian.

Bulk-edit entity priority, policy, lag, tags

Capability:

Mass operations UI + REST.

How:

Multi-select in the Tenant Home tables, then bulk-apply priority / SLA / tags / monitoring-time / ACK / disable / re-enable. Equivalent REST endpoints under /trackme/v2/<component>/... and /trackme/v2/ack/*.

See also:

Performing mass operations in TrackMe.

Replay configuration changes resiliently

Capability:

TA-trackme-conf-manager (companion add-on).

How:

A KV-backed transactional layer that accepts a TrackMe REST transaction, persists it, and replays it on a 15-minute schedule until it succeeds. Useful for SOAR playbooks, infrastructure-as-code pipelines, and any orchestrator that must guarantee a configuration change eventually lands. See TrackMe Ecosystem — Companion Add-ons for details.

Back up and restore tenants independently — multi-archive 3.0.0

Capability:

Multi-archive backup & restore (release 2.3.22+).

How:

A backup run produces N+1 independent archives — one per enabled tenant + one global archive — each individually validated (zstd -t + SHA-256) and individually restorable. A failure in one archive does not block the others, by design. Three restore modes: single archive, whole run, or legacy flat (pre-2.3.22 monolithic). SHC-aware (per-archive operations delegate to the owning peer). Missing-tenant safety guard automatically recreates a tenant record from the archive’s own vtenant_account JSON if restoring on an install where the tenant is absent.

See also:

Backing up and Restoring TrackMe.

I want to integrate with my downstream incident-response stack

Push to Splunk ES — notable events

Capability:

Notable event alert action.

How:

trackme_notable writes events to a notable index (default trackme_notable) consumable by Splunk Enterprise Security’s notable event framework.

See also:

Notable events.

Push to Splunk SOAR (Phantom) — containers and active commands

Capability:

Splunk SOAR push (built-in) + active commands on stateful alerts.

How:

TrackMe stateful alerts can run active commands on open / update / close — any generating or streaming search command, parameterised with the alert’s payload. The most common use is | trackmesplksoar to push containers / events into SOAR. trackme-app-on-soar (a Phantom-side connector) provides the inverse integration: SOAR playbooks calling TrackMe REST to ACK entities, enable / disable maintenance, retrain ML models, manage logical groups, etc.

Push to Cortex XSOAR (Palo Alto) — bidirectional incident lifecycle

Capability:

TA-trackme-xsoar (companion add-on).

How:

Active-command integration on TrackMe stateful alerts: commands_opened creates an XSOAR incident, commands_updated patches it with new state, commands_closed closes it. A built-in resilient retry store (KV-backed, 15-minute replay) guarantees incident parity even through network blips or XSOAR outages. See TrackMe Ecosystem — Companion Add-ons.

See also:

Palo Alto XSOAR Integration.

Trigger any TrackMe REST endpoint from any saved search firing

Capability:

Free-style REST call alert action.

How:

trackme_free_style_rest_call invokes any /trackme/v2/* endpoint (GET / POST / DELETE) when the saved search fires. Useful for custom orchestration: bulk-ACK from a correlation search, force-disable entities from an upstream change-management signal, trigger a smart status investigation from an external context.

I want to extend or customise TrackMe

Add a custom check to an existing entity (any component)

Capability:

Hybrid trackers (per-component).

How:

A custom SPL check that runs alongside the default component logic and contributes score / state / anomaly_reason / enrichment to the entity’s final state.

Edition gate:

Foundation rejects; Enterprise caps at 8 per tenant; Unlimited is uncapped.

Replicate a tracked entity set into another TrackMe instance

Capability:

Replica trackers.

How:

One-way replication, source state trusted (no local re-evaluation). Useful when a central TrackMe must present entities owned by remote regional TrackMes.

Persist arbitrary TrackMe configuration as code

Capability:

TA-trackme-conf-manager + /trackme/v2/* REST API.

How:

Define entities, policies, thresholds, ACKs, maintenance windows via REST; wrap them in conf-manager transactions for guaranteed delivery. Suitable for Ansible / Terraform / GitOps integration.

Orchestrate TrackMe from Splunk SOAR playbooks

Capability:

trackme-app-on-soar (a Splunk SOAR / Phantom connector, not a Splunk TA).

How:

Exposes TrackMe REST endpoints as SOAR actions: test connectivity, ack_get / ack_manage, maintenance_*, tenants_ops_status, remote_accounts_check_connectivity, ml_outliers_*, component_get_entity / component_manage_entity, smart_status, logical_group_*. Asset configured with a Splunk bearer token. Powers playbook-driven runbooks (e.g. ACK on upstream CMDB change, disable maintenance after deploy completes).

See also:

TrackMe Ecosystem — Companion Add-ons, TrackMe App on SOAR.

What if my goal isn’t covered above?

The pre-built FLX template library is one of TrackMe’s broadest surface areas but it is not exhaustive. The FLX (Flex Objects) Use Case Template Catalog page ends with a “Coverage gaps not addressed out of the box” section listing the recurring asks we know about (auth-failure spikes, scheduler skip-rate per user / app beyond what WLK does, app-version drift, etc.).

When you have a goal not addressed by a template or a built-in feature, your three options, in increasing order of effort, are:

1. Author a custom FLX use case through the wizard — see FLX — Flex Objects.

2. Add a hybrid tracker to an existing entity — see Hybrid trackers.

3. Build the data path via a companion TA (Cribl, Google SecOps, lookup monitor) and feed the data into FLX. See TrackMe Ecosystem — Companion Add-ons.

If a use case feels generally applicable across customers, contributing a JSON file back to package/lib/flx_library/ makes it available to every TrackMe deployment.