TrackMe Adoption Roadmap

What this page is

A descriptive map of the journey we typically see TrackMe customers travel through, organised in six phases. It is not a prescriptive “you must do X before Y” ladder — every customer moves at their own pace, and the right sequencing depends on team maturity, scale, and what brought them to TrackMe in the first place.

What we do observe consistently is that certain capabilities are counter-productive if enabled too early — a customer still stabilising on data-source monitoring will be hurt, not helped, by turning on ML outliers and AI status reports on day one. This page makes those anti-patterns explicit so you can resist the temptation to enable everything at once.

Audience:

Existing TrackMe customers looking for “what should I focus on next?”, new customers planning a rollout, account teams and partners wanting a shared mental model.

Companion pages:

TrackMe Use Cases — Organised by User Intent (what you can do), TrackMe Capability × Component Matrix (which features apply to which components), FLX (Flex Objects) Use Case Template Catalog (pre-built use cases), TrackMe Ecosystem — Companion Add-ons (companion add-ons).

The shape of the journey

The six phases below are the rhythm we see across most TrackMe deployments — from small Foundation tenants to large multi-tenant Unlimited estates:

Phase

Focus

Customer question that triggers it

1

Data source monitoring (DSM)

“Is my data still arriving as expected?”

2

Hosts and endpoints (DHM)

“How do I know an individual host stopped sending data?”

3

Volume outliers with ML (FLX volume tenant, or DSM merged-mode outliers on Foundation)

“Now that I track feeds and hosts, how do I detect abnormally low or high volumes?”

4

Workload Knowledge (WLK) — optional interlude

“Can I extend TrackMe to monitor Splunk’s own scheduled-search health?” — usually prompted by us, not by the customer

5

Flex expansion, Splunk infra, third-party

“What else can I monitor with TrackMe?”

6

Steady state — governance, growth, what’s next

“How do we keep TrackMe alive, growing, and shared across teams?”

Note

Phase 4 is deliberately framed as an optional interlude, not a sequential gate. Workload Knowledge is one of TrackMe’s most valuable components, but it is rarely what attracts customers to the product in the first place — it is a capability we proactively teach about when the customer is ready, rather than one they ask for. Some customers adopt WLK between phase 2 and phase 3; others much later; some not at all.

How we work with you through the phases

There are no fixed durations and no hard gates. The pattern we follow:

  • We periodically prompt you about what’s typically next — through release notes, account-team conversations, or the AI Assistant surfacing capabilities you have not yet enabled.

  • You decide pace and order based on what your team is ready for, what the data is telling you, and what your stakeholders are asking about.

  • The TrackMe Use Cases — Organised by User Intent and FLX (Flex Objects) Use Case Template Catalog pages are the menu; this page is the suggested order.

Phase 1 — Data source monitoring

The customer question that opens this phase

“Is my data still arriving as expected — and how do I get told the moment it stops?”

This is the phase that brought most customers to TrackMe in the first place, and it is where every deployment starts. The goal is to know, reliably and quickly, when a data feed is no longer arriving on time — nothing more, nothing less.

Primary focus

  • Component: DSM (Data Source Monitoring), tracking (index, sourcetype) feeds.

  • Primary KPI: ingestion delay (how long ago we last received data). Secondary KPI: latency (the gap between event time and index time).

  • Tenant pattern: one or two DSM-only tenants, usually scoped by organisational responsibility (e.g. one tenant per data team, or one per environment).

See QUICK START - Starting with TrackMe: (feed tracking quickstart) for the canonical walkthrough.

What we typically build first

  • The default DSM tracker, discovering (index, sourcetype) entities automatically.

  • Static delay thresholds tuned to the customer’s expectations, or variable delay thresholds (day-of-week × hour-of-day) if there are predictable business-hours / overnight patterns.

  • Email-based stateful alerting (open / update / close) so each real state transition produces exactly one notification thread.

  • Initial design of the alerting workflow: do notifications go to email only, to a third-party ITSM / ticketing platform, or both? This decision is usually revisited later, but it is worth agreeing on a starting point at phase 1.

Fighting the noise

The most important phase-1 skill is classification — separating the few feeds that genuinely matter from the many that do not. The TrackMe concepts that earn their keep here:

  • Priority policies (regex / lookup / SPL) — assign critical / high / medium / low / pending priorities without touching individual entities.

  • Tag policies — attach routing labels (team:auth, env:prod) that survive entity recreation.

  • SLA policies — bucket entities into platinum / gold / silver classes for uptime accounting.

  • Notes and labels — document feeds as the team learns about them (“re-deploy at 03:00 on 2026-05-08, root cause INC-12345”).

See Priority, Tags, and Using SLA alerting to build a 2-tier monitoring system.

Organisational dimension

Phase 1 is where the customer’s team learns the product — what an entity is, what a tenant is, how the stateful alerting workflow feels, what categorisation conventions to use. Most customers spend significant time here, and that is healthy: skipping ahead before the team is comfortable creates noise debt that compounds in every later phase.

What to not do yet

Resist the temptation to enable the following in phase 1 — they will generate noise faster than the team can metabolise it:

  • ML outlier detection — the data has not had time to train stable models, and even if it has, the team is not yet equipped to triage outlier alerts.

  • AI status reports in alert emails — useful, but adds cognitive load before the basics are mastered.

  • Hybrid trackers, logical groups, and smart-status investigations — all valuable later, but premature here.

The right phase-1 alert is a clean “this feed has stopped, here is the priority and SLA class, here is who to call”. Build that solidly before layering anything else on top.

Edition variants

  • All editions support phase 1 in full.

  • Foundation has DSM, DHM, MHM and one tenant only — perfect for phase 1.

Phase 2 — Hosts and endpoints

The customer question that opens this phase

“Now that I monitor my feeds, how do I know when an individual host stops sending data — even if its index and sourcetype are still busy from other hosts?”

This is the natural follow-up to phase 1. Feeds answer “is this data flowing at all?”. Hosts answer “is this specific machine flowing?”. Most customers reach phase 2 within weeks or a few months of phase 1.

Primary focus

  • Component: DHM (Data Host Monitoring), tracking host × sourcetype activity.

  • Tenant pattern: a dedicated DHM tenant (sometimes several). Mixing host tracking into the existing feeds tenant is the most common phase-2 mistake — the volumes and the operational lifecycle are different enough that they deserve their own container.

  • Break-by mode: most deployments start with one entity per (host, sourcetype) pair. TrackMe 2.3.23+ supports breakby_extra_fields on DHM hybrid trackers, which lets you add extra metadata dimensions (e.g. source) to the combo grain — use this when (host, sourcetype) alone does not separate the activity enough.

See Hybrid trackers and Notes.

The scale challenge

Large customers can have tens of thousands of endpoints across heterogeneous fleets — servers, network gear, Windows desktops, Linux containers, IoT, third-party agents. Three considerations dominate:

  • Inventory quality — does the customer have a usable CMDB? If yes, integrate it (priority, tags, SLA all driven by lookup or SPL-search policies against the CMDB). If no, this is the right moment to start one.

  • Discovery scope — use the DHM blocklist and allowlist aggressively. Tracking every device on the wire is rarely what you want; tracking the hosts that belong to a known inventory is.

  • Tenant design — multiple DHM tenants by responsibility area (e.g. one per OS family, one per business unit) is often clearer than one mega-tenant.

See CMDB integration for the CMDB integration patterns and QUICK START - Design and automate through lookup knowledge for the lookup-driven approach.

Organisational dimension

Phase 2 typically pulls in a wider set of stakeholders than phase 1: endpoint owners, OS teams, CMDB owners, sometimes security. The operational rhythm of “an endpoint went silent” is genuinely different from “a feed went silent” — it usually means a host is down, an agent is broken, or someone decommissioned a machine without telling anyone. Phase 2 is where TrackMe starts being a cross-team conversation.

What to not do yet

  • ML outlier detection on DHM — per-host event volume is too noisy in most environments to model usefully. The DHM defaults in TrackMe (mloutliers_dhm=0) reflect this — leave outliers off here.

  • Logical groups before the discovery scope is stable — group membership is only useful once you trust what is being discovered.

Edition variants

  • All editions support DHM.

  • Foundation supports DHM but is limited to one tenant — for very large endpoint fleets, Enterprise or Unlimited is usually a better fit because you can split the load across multiple tenants.

Phase 3 — Volume outliers with Machine Learning

The customer question that opens this phase

“Now that I monitor feeds and hosts for primary KPIs, how do I detect that I am receiving unusually low or unusually high volumes of events — without writing thresholds by hand?”

Phase 3 introduces TrackMe’s machine-learning outlier detection as a behavioural-anomaly layer on top of the deterministic phase 1 + phase 2 monitoring. Two distinct deployment patterns exist depending on edition.

The Enterprise / Unlimited pattern: a dedicated FLX volume-outliers tenant

This is the recommended pattern when the customer has the edition for it. The shape:

  • A dedicated tenant for volume outliers, kept separate from the main feeds tenant.

  • Built on the FLX pre-built use cases splk_license_usage_global_splunkenterprise / splk_license_usage_per_index_splunkenterprise (or the Splunk Cloud equivalents) — see FLX (Flex Objects) Use Case Template Catalog.

  • Why FLX over per-sourcetype DSM outliers: the license-usage feeds are scalable and pre-aggregated (MB per index, even at large scale) and they focus on the index level, which is the right granularity for volume anomaly detection. Per-sourcetype noise is filtered out by construction.

  • Native ML outlier detection (DensityFunction with optional weekly seasonality) on the rolling 60-minute / 4-hour / 24-hour KPIs.

See Outlier detection for the ML configuration and QUICK START - TrackMe Impact-Based Alerting (IBA) for how outlier breaches contribute to entity state.

The Foundation pattern: built-in DSM outliers in merged mode

Foundation customers do not have FLX, but they can achieve similar behaviour with the built-in DSM outlier detection running on a DSM tracker in merged mode. Merged mode aggregates the entity’s event-count metrics across sourcetypes for the same index, giving the ML model a clean per-index volume signal to learn from.

The trade-off: the volume-outlier signal lives inside the main feeds tenant rather than in a dedicated container. This is operationally simpler but conceptually less clean — most teams find it easier to separate “is this feed flowing?” from “is this feed volume anomalous?” even though the underlying data overlaps.

Organisational dimension

Phase 3 is where TrackMe usage starts to look more like an L3 / specialist activity. The questions get sharper:

  • Who triages a volume outlier alert? (Different role from the L1 / L2 triage for a delay alert in phase 1.)

  • How is priority propagated from the main feeds tenant into the volume-outliers tenant? Most commonly: a priority policy (lookup-based or SPL-search-based) in the volume-outliers tenant reads from the main feeds tenant so an entity that is critical for feed monitoring is also critical for volume monitoring — automatically.

  • What is the alert workflow for outlier signals? Often quieter than delay alerts (no auto-pager), routed to a dashboard or a daily digest rather than waking someone up at 03:00.

What to not do yet

  • Enabling outliers on every component indiscriminately — DHM, MHM, FQM, WLK are generally not good outlier candidates (see TrackMe Capability × Component Matrix). Outliers are a focused per-component opt-in, not a fleet-wide switch.

  • Volume outliers in the main feeds tenant on Enterprise / Unlimited — defeats the purpose of having FLX. Keep them separate.

Edition variants

  • Foundation: built-in DSM outliers, merged-mode tracker, single tenant.

  • Enterprise and Unlimited: dedicated FLX volume-outliers tenant, recommended.

Phase 4 (optional interlude) — Workload Knowledge

The customer question that opens this phase

“Can I extend TrackMe to monitor Splunk’s own scheduled-search workload — skip rates, errors, slow runs, orphaned owners?”

This is the phase customers most often arrive at because we tell them about it, not because they asked. Workload Knowledge (WLK) is one of TrackMe’s most valuable components, but it is rarely the use case that attracted them to the product in the first place.

Why we proactively teach it

WLK fills a category that Splunk itself does not address well: the health of the scheduler estate — which searches skipped, which errored, which take dramatically longer than they used to, which run as a user who no longer exists, which live in an app that has been disabled. Most large Splunk estates accumulate scheduler debt silently over years; WLK surfaces it in a structured way.

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

Where it slots into the journey

Not strictly. Some customers adopt WLK between phase 2 and phase 3 because they hit a scheduler-noise problem early. Some adopt it alongside phase 5 as part of the broader Splunk-infrastructure expansion. Some never adopt it. We do not gate other phases on it.

Primary focus

  • Component: WLK, tracking scheduled searches.

  • Tenant pattern: a dedicated WLK tenant.

  • Tenant-default threshold row — a WLK-specific feature where a single object_id == "default" record provides the fleet-wide fallback threshold; per-entity rows act as exceptions. Use this pattern to manage thresholds at the tenant level with a small number of overrides, rather than configuring every entity.

  • Signals to watch: skip rate, error count, execution-time drift, versioning (the savedsearch definition has changed since the fingerprint was taken — surfaces unannounced edits), orphan owners, app enablement.

What to not do yet

  • ML outliers on WLK — scheduler metrics are discrete (skip count, error count); thresholds are the right tool, not density-function models.

Edition variants

  • Foundation: does not include WLK. Customers on Foundation must upgrade to Enterprise or Unlimited to enter this phase.

  • Enterprise and Unlimited: full WLK support.

Phase 5 — Flex expansion, Splunk infrastructure, third-party

The customer question that opens this phase

“What else can I monitor with TrackMe — both inside Splunk and outside?”

Once phases 1 – 3 are operational and the team is comfortable, phase 5 opens up the full breadth of TrackMe’s monitoring catalogue. There is no single “right” order here — the choice is driven by what is most valuable to the customer.

Common phase-5 workstreams

  • Splunk platform deep-dive — indexer cluster status, SHC member health, bucket health, KV-store readiness, queue saturation, parsing errors, DMA acceleration, HEC errors, UF version compliance, knowledge-bundle size. See the splunk_infrastructure and splunk_data_collection categories in FLX (Flex Objects) Use Case Template Catalog.

  • License and cost monitoring — pool usage, rolling volume windows, per-index attribution. (Splunk Cloud: storage and SVC consumption by app and by consumer service.)

  • Splunk good-practices auditing — all-time scheduled searches, user-owned searches, dynamic sourcetypes (the splunk_good_practices category).

  • Splunk SOAR monitoring — playbook concurrency and failures, asset health, automation broker HA, infra load / memory, services health, SOAR-to-Splunk forwarding. See Splunk SOAR.

  • Cribl Stream / Cribl Edge monitoring (if the customer has Cribl in the stack) — input / output health, pipeline traffic, route shifts with ML outliers, host CPU. See Cribl monitoring and TrackMe Ecosystem — Companion Add-ons for the companion add-on.

  • Field-quality monitoring (FQM) for CIM compliance and parsing accuracy. See Use Case Demo: Fields Quality (CIM and non-CIM).

  • Host OS monitoring for Linux (TA-nix) and Windows (Splunk_TA_windows) fleets — CPU / memory per host with avg / max / p95.

Organisational dimension

Phase 5 is where TrackMe stops being a tool that one team runs and becomes a tool that many teams consume. Different workstreams have different owners — the Splunk platform team for infrastructure, the licensing / FinOps team for cost monitoring, the SOC for SOAR, the data team for parsing quality. Virtual Groups become valuable here as read-only cross-tenant aggregation views for executives or central teams (see QUICK START - Cross-tenant domain views with Virtual Groups).

This is also the phase where customers often integrate TrackMe with their downstream incident-response stack — Splunk ES (notable events), Cortex XSOAR (active commands), Splunk SOAR playbooks. See TrackMe Ecosystem — Companion Add-ons.

What to not do yet

  • Enable every FLX template at once — the catalog is large; 48 of the 65 templates run on a 5-minute cadence by default, so a bulk enablement can spike the scheduler load. Stagger by editing uc_cron offsets at enablement time, or roll out workstreams one quarter at a time.

Edition variants

  • Foundation: phase 5 is largely inaccessible — no FLX, no WLK.

  • Enterprise and Unlimited: full phase 5.

  • Unlimited: also unlocks unlimited hybrid trackers and remote Splunk deployments.

Phase 6 — Steady state: governance, growth, what’s next

The customer question that opens this phase

“TrackMe is now a central part of how we run monitoring — how do we keep it alive, growing, and shared across the team?”

Phase 6 is the steady state, not a destination. The platform is widely adopted, multiple teams receive alerts from it or work inside it, and the question shifts from “what do we turn on next?” to “how do we keep what we have healthy, and how do we keep growing?”.

Unlike phases 1 – 5, phase 6 does not have a feature checklist. It has four themes that all operate continuously.

People — building a champion network

  • Expand the champion base over time. A single TrackMe expert is a single point of failure. Spread knowledge across multiple team members, ideally across multiple teams.

  • Cross-team training. SOC, IT ops, observability, business owners — each consumes TrackMe differently. Run targeted training sessions per audience, not one-size-fits-all.

  • Rotation and handoff hygiene. When a champion leaves the team or the company, their TrackMe knowledge needs to leave with them intentionally, through documented handoff, not through luck.

Process — periodic review and gap analysis

  • Periodic gap analysis against the FLX (Flex Objects) Use Case Template Catalog. Every quarter (or whatever cadence fits): walk the catalog with the team and ask “is there anything we should have enabled and have not yet?”. The catalog grows with every TrackMe release.

  • Quarterly Configuration Guardian sweep. Guardian flags drifting configuration (missing capabilities, stale tokens, missing indexes, unreachable AI provider, stale backup archives, dead health tracker). Treat the Guardian alerts list as part of the ongoing platform review, not as one-off pop-ups.

  • Tenant lifecycle hygiene. Decommission tenants for projects that have wound down. Prune dormant entities. Review priority / tag / SLA policies for relevance — yesterday’s regex might catch the wrong things today.

Platform — keeping the foundation healthy

  • Configuration Guardian as a continuous safety net — see TrackMe Capability × Component Matrix for the full list of checks.

  • Backup and restore discipline. TrackMe 2.3.22+ ships a multi-archive backup format where every tenant and the global state are independent archives. Keep the backup scheduler enabled, test restore periodically, and use the per-tenant restore mode for targeted recovery rather than blanket rollbacks. See Backing up and Restoring TrackMe.

  • License and cost management. As the platform grows, license-edition fit can drift — what was right at adoption may not be right at steady state. Review periodically.

  • Version-upgrade hygiene. Read release notes, schedule upgrades with the same care as Splunk itself, and use a non-production tenant to validate before rolling out.

Forward look — what’s coming next

  • New FLX templates ship with most TrackMe releases — re-read the FLX (Flex Objects) Use Case Template Catalog after each release to see what is new.

  • Companion add-ons evolve — Cribl, XSOAR, conf-manager, Google SecOps all gain features over time; check TrackMe Ecosystem — Companion Add-ons periodically.

  • AI Agents — the next major evolution of the AI Assistant work is moving towards autonomous AI Agents that can act on TrackMe state (triage, ACK, investigate, recommend remediations). This is on the TrackMe roadmap and will become a phase-6 topic in its own right once it ships.

  • Periodic check-in with the vendor. We (TrackMe) will periodically reach out about what’s new and what is worth your time. Treat these conversations as part of the adoption journey rather than as interruptions — the platform is still growing, and so is your usage of it.

Closing thought

TrackMe is never finished. The platform keeps growing, the customer keeps growing, and the adoption journey is iterative — most customers revisit earlier phases as their estate evolves (new business units, acquisitions, new data sources, new Splunk deployments to monitor remotely). The six phases above are a map, not a ladder, and the right answer to “where am I on the roadmap?” is almost always “in several places at once”.

If you are unsure where to focus next, the shortest path is:

  1. Run the gap-analysis checklist at the bottom of FLX (Flex Objects) Use Case Template Catalog.

  2. Scan the TrackMe Use Cases — Organised by User Intent for goals you have not yet addressed.

  3. Cross-check the TrackMe Capability × Component Matrix for features you could enable on components you already use.

  4. Reach out to us — the periodic teach-back conversation is exactly what this page is designed to support.