Checks Reference

Verifies that all Monitoring Console peers are configured and healthy. Issues here indicate instances that are visible to the MC but not fully configured for assessment.

Verifies that a customer name has been entered in the 1 - Set up page. All check results are tagged with this name. Without it, results cannot be exported or identified correctly.

Verifies that the core license value has been set in setup. Required for accurate cloud sizing and SOW generation.

Identifies Search Heads that are dispatching searches but have not been added to the Monitoring Console configuration. These "rogue" instances may distort assessment results if excluded.

Measures hourly license utilization over the past 7 days. Identifies peak ingestion periods that may affect Splunk Cloud tier selection.

Verifies that valid licenses are installed and active. Expired or missing licenses can affect the assessment and the migration scope.

Reports daily ingest volume against license for the past 30 days. Used to establish the cloud ingest tier and identify license violations.

Checks the ratio of premium app license (ES, ITSI, etc.) to core license. An imbalanced ratio may indicate licensing issues that need to be addressed before migration.

Inventories all index definitions and checks compatibility with Splunk Cloud naming conventions and restrictions.

Estimates the number of Splunk Cloud storage blocks required based on current indexed data volumes. Used to size the cloud storage tier.

Counts active indexes and compares against the Splunk Cloud limit. Environments near or over the limit need index consolidation planning before migration.

Compares configured index retention periods against Splunk Cloud defaults. Indexes with non-standard retention may require additional cloud storage or policy adjustments.

Looks for event-processing warnings in the past 24 hours. Parsing issues in the source environment will carry over to cloud and should be addressed before migration.

Identifies events with timestamps in the future. Future-dated events are discarded by Splunk Cloud by default, so they need to be investigated before migration.

Reports the amount of data stored per index. Used to size cloud storage and identify indexes with unexpectedly large footprints.

Checks whether SmartStore is in use. SmartStore customers have specific migration path considerations distinct from traditional on-premises storage.

Identifies sourcetypes automatically assigned by Splunk's learned sourcetype mechanism in the past 7 days. Learned sourcetypes should be reviewed and formalized before migration.

Enumerates all data sources (host, source, sourcetype) indexed in the past 7 days. Provides a complete picture of what data is flowing into the environment.

Checks for full forwarding or indexing queues. Blocked queues indicate the environment is under stress and may be losing data.

Identifies searches that have been skipped due to resource constraints. Skipped searches indicate the environment is under load and may have SLA-impacting issues in cloud.

Provides the detail of individual searches that have been skipped. Use in conjunction with SCMA-016 to investigate root cause.

Identifies searches running longer than 5 minutes. Long-running searches in cloud environments can consume workload pricing credits quickly and may need optimization.

Measures search throughput over the past 7 days. Used to right-size the cloud search tier.

Reports search concurrency statistics over the past 7 days, including peak concurrent searches. Used to validate cloud search head sizing.

Compares the environment against the Sweet Spot (allowed ingest volumes) for the configured license type. Environments outside the Sweet Spot require special sizing consideration.

Determines whether the environment qualifies for Splunk Cloud workload pricing based on search patterns and resource utilization.

Analyzes search time range patterns over the past 90+ days. Searches spanning very large time ranges are indicative of expensive compliance-type searches that need to be assessed for cloud.

Counts active real-time searches. Real-time searches consume more resources than scheduled searches and are restricted in Splunk Cloud.

Counts enabled ES correlation rules. High counts may exceed Splunk Cloud ES limits and need to be reduced before migration.

Reports ES data model accelerations configured in the environment. Accelerations have storage and performance implications in Splunk Cloud.

Counts ITSI aggregation policies. Checks against Splunk Cloud ITSI limits.

Counts ITSI correlation searches. Checks against cloud limits for ITSI deployments.

Counts the number of ITSI services configured. Checks against Splunk Cloud ITSI service limits.

Identifies scheduled searches that have alert actions configured. These searches may need reconfiguration in Splunk Cloud if the action target changes post-migration.

Lists the top 50 dashboards by CPU and memory usage over the past 30 days. Heavy dashboards may need optimization before cloud migration to avoid workload pricing impacts.

Lists the top 50 search jobs by CPU and memory usage over the past 30 days.

Checks distributed search health by looking for result accuracy issues. Indicates whether all search peers are responding correctly to federated queries.

Measures the size of the search bundle. Splunk Cloud has a search bundle size limit; environments exceeding it will need to reduce knowledge object content before migration.

Identifies scheduled searches that have returned no results in the past 14 days. These may be orphaned or misconfigured searches that can be cleaned up before migration.

Detects non-default search limit configurations (e.g. max_searches_per_cpu). Modified limits may not be transferable to cloud and could cause behavioral differences post-migration.

Identifies the most popular apps in use over the past week by page view activity. Used to scope which apps need cloud vetting as part of migration.

Checks whether installed apps have been vetted for Splunk Cloud. Unvetted apps cannot be installed in cloud environments and will need to go through AppInspect before migration.

Identifies apps that have local directory overrides. Local overwrites indicate customizations that may not survive a standard app migration and need to be reconciled.

Inventories private (user-owned) knowledge objects — transforms, dashboards, saved searches, etc. Private content must be migrated separately and may require user re-provisioning.

Reports forwarder count and version breakdown. Older forwarder versions may not be compatible with Splunk Cloud's certificate requirements and will need upgrading before migration.

Checks whether forwarder output throughput throttling is configured. Throttled forwarders may not be delivering all data to indexers, which affects the accuracy of the assessment.

Identifies forwarders that are unable to send data to their configured outputs. Connection issues need to be resolved before migration.

Reports HEC (HTTP Event Collector) usage over the past 7 days — token counts, event volumes, and source details. HEC senders need to be reconfigured to point to the cloud HEC endpoint post-migration.

Measures the share of users in the admin role. A high admin ratio indicates a security posture that may need to be tightened before migrating to Splunk Cloud.

Reports user counts and authentication methods in use (LDAP, SAML, native, etc.). Authentication configuration needs to be replicated in Splunk Cloud and may require IdP coordination.

Counts distinct users who have authenticated in the past 30 days. Used to scope user migration and license entitlement for Splunk Cloud.

Inventories all instances with OS, Splunk version, and role. Provides a complete picture of the environment topology and identifies outdated Splunk versions that may block migration.

Looks for Splunk crash logs in the past 7 days. Crashes indicate underlying stability issues that should be resolved before migration. Review the crash event and frequency; consider upgrading if on an older version.

Counts all knowledge objects by type and app. Used to scope the knowledge migration effort and to identify potential bundle size issues.

Identifies instances with consistently high CPU load averages. High CPU may indicate under-provisioned hardware or runaway searches that need to be addressed before migration.

Measures KV Store collection sizes against Splunk Cloud limits (25 GB per collection, 100 GB total). Collections exceeding these limits need to be reduced or archived before migration.

Identifies dashboards that have not been used in the past 30 days. Unused dashboards can be cleaned up to reduce migration scope and bundle size.

Identifies lookup definitions that have not been used in the past 30 days. Unused lookups can be archived or removed before migration.

Identifies SPL macros that have not been used in the past 30 days. Unused macros can be removed to reduce migration scope.