Splunk Enterprise Updates & Release Notes

What's new in 10.4

Splunk Enterprise 10.4 was released on May 18, 2026.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known issues for this release.

Planning to upgrade from an earlier version?

If you plan to upgrade to this version from an earlier version of Splunk Enterprise, read How to upgrade Splunk Enterprise in the Installation Manual for information you need to know before you upgrade.

See About upgrading: READ THIS FIRST for specific migration tips and information that might affect you when you upgrade.

The Deprecated and removed features topic lists computing platforms, browsers, and features for which Splunk has deprecated or removed support in this release.

• Index-based Search Targeting

Index-Based Search Targeting is a new enhancement for Federated Search in transparent mode. This feature allows administrators to route search requests directly to specific providers based on index-to-host mappings, providing you with greater control over your search environment. Index-based search targeting provides the following key benefits:

• Enhanced Security: By restricting searches to specific hosts, you minimize the exposure of sensitive information and ensure that query logs are only accessible where necessary.
• Optimized Performance: Reduce system overhead and improve search speeds by eliminating unnecessary requests, which allows your infrastructure to focus resources only on relevant search providers.

This update ensures a more secure, streamlined, and efficient search experience across Federated Search for Splunk environments.

Administrators can now use the following new REST endpoint arguments to configure index-based provider selection for Federated Search for Splunk by specifying which indexes federated search heads can access from federated providers when operating in transparent mode:

• The data/federated/settings/general endpoint: The allowIndexBasedProviderFiltering argument enables index-based filtering for federated providers.
• The data/federated/provider/{federated_provider_name} endpoint: The fedSrchIndexesAllowed argument specifies the indexes that are accessible from each federated provider.

See Federated search endpoint descriptions in the REST API Reference.

• Improvements to Edge Processor pipeline previews and updated SPL2 support

The Edge Processor service has been upgraded to improve the accuracy of pipeline previews, allowing full support for additional SPL2 commands such as decrypt and ocsf. For information about the SPL2 commands and functions that are supported in this release, see Edge Processor pipeline syntax in the Use Edge Processors for Splunk Enterprise manual.

• Custom pipeline templates for Edge Processors

You can now create and use custom pipeline templates that are provided through SPL2-based apps. If an app that contains templates is installed on Splunk Enterprise, those templates become available on the Pipelines page and during the pipeline creation workflow. See Create custom pipeline templates in the Splunk Developer Guide for information on creating a template and including it in an app. See Use templates to create pipelines for Edge Processors in the Use Edge Processors for Splunk Enterprise manual for information on creating a pipeline by using a template as a starting point.

• Support for running Edge Processor in Federal Information Processing Standards (FIPS)-compliant mode.

Edge Processor now supports running with FIPS-compliance enabled, which is required in order to work within FedRAMP Moderate environments. This update lets government agencies and organizations with strict regulatory requirements leverage Edge Processor while maintaining compliance with federal security standards. See Set up an Edge Processor for more information.

• Edge Processors on Splunk Enterprise can successfully reconnect to the control plane after an extended disconnect

The Edge Processor service has been upgraded to automatic reconnection to the control plane after an extended disconnection period. For information about how to upgrade existing Edge Processors to automatically reconnect, see Upgrade Edge Processor to automatically reconnect in the Use Edge Processors for Splunk Enterprise manual.

• Additional match types and configuration options in the lookup command for Edge Processor pipelines

You can now configure lookups that use CIDR matching and wildcard matching. You can also optionally configure lookup matches to be case-sensitive, or require a minimum or maximum number of matches to be returned in the output. To specify these new configurations, you must manually enter the corresponding command arguments in the pipeline editor. For information about the supported syntax for the lookup command, see lookup command: Overview, syntax, and usage in the SPL2 Search Reference.

• Apply custom command function action for Edge Processor pipelines

To process the incoming data before sending it to a destination, you can now discover, select, and apply custom command functions, which are user-defined SPL2 functions. This is particularly helpful for customers with less experience using SPL2. See Create and apply a custom command function for the Edge Processor solution in the Use Edge Processors for Splunk Enterprise manual for more information.

• Additional new Dashboard Studio features

This release adds various new features for Dashboard Studio, including the following:

• Token Manager UI to view all tokens in a dashboard. See Token manager.

• New network graph visualization to visualize entities and the relationships between them. See Network graph.

• Accelerated render option for line charts with improved performance and responsiveness. See Accelerated render line chart example.

• Dashboards resource management

Running auto-refresh searches when viewing dashboards now requires the new auto_refresh_dashboards capability, which Splunk admins can choose to grant to user roles. Admins can also deactivate dashboards as needed. See Manage dashboard resource consumption.

Note: This is a change in default behavior. In earlier Splunk versions, all users could run auto-refresh searches. After upgrade to 10.4, only the admin and sc_admin roles have the auto_refresh_dashboards capability by default. Users with the admin and sc_admin roles will need to assign the capability to other user roles.

• New Dashboard Studio custom visualizations framework

Dashboard Studio supports custom visualizations built using the new custom dashboard extension framework for Dashboard Studio, which offers increased flexibility, simplicity, and performance. With the new framework, you can leverage modern libraries compared to the old custom visualizations framework for simple XML dashboards. See Custom visualizations for Dashboard Studio.

• Cisco One Look & Feel - Modern Navigation Adoption (GA)

Modern Navigation shifts the traditional top navigation bar to a sleek, side navigation panel complemented by an updated header. Designed to deliver a consistent, accessible experience, Modern Navigation is a part of our overall vision of a cohesive look and feel across Splunk and Cisco products. See Modern navigation UI changes.

• Bulk Data Move - support for CLI and SmartStore

You can now perform bulk data moves between SmartStore-backed indexers. Additionally, the Bulk Data Move toolset is now accessible through the Splunk CLI on the Cluster Manager, offering a command-line alternative to the existing REST API for automation and troubleshooting. See Bulk Data Move for indexer clusters in the Manage indexers and indexer clusters manual.

• Splunk topology API

Using the Topology REST API, admins and applications gain programmatic access to deployment topology and infrastructure introspection data through a unified interface. The endpoints retrieve information using the Splunk Topology sidecar.

The Splunk Topology API provides administrators with an automated, authoritative source for deployment and infrastructure data, streamlines complex workflows like app installations and release upgrades, and eliminates the need for manual input. See Topology endpoint descriptions in the REST API Reference manual.

• HTTP/2 support for Splunk Web UI

Splunk Web now supports the HTTP/2 protocol, which uses multiplexed communication to handle browsing activity in parallel. This significantly improves performance for complex dashboards, simultaneous searches, and multi-tab browsing compared to the sequential processing of HTTP/1.1.

HTTP/2 is supported on Linux and macOS environments.

HTTP/2 is deactivated by default and requires activation. See Activate HTTP/2 to enhance Splunk Web performance in the Admin manual.

• SHA-1 Certificate Support Removed

As of Splunk platform 10, SHA-1 certificates are no longer supported. Customers will need to apply new certificates not using this standard. The Splunk Cloud Monitoring Console and Splunk Enterprise Monitoring Console have previously been updated to report on SHA-1 related warnings and errors raised by the Splunk platform, and customers can continue to use these tools to navigate the change.

• App context for Federated Search for Splunk in standard mode

The new update for the app context for Federated Search for Splunk in standard mode introduces a more flexible approach to managing application contexts that gives users a more intuitive experience and simplifies how search contexts are handled. This update allows the federated provider to align with the application context of the search performed on the local federated search head; by default, Splunk platform on standard mode federated providers reflects the context of the user's local search environment.

This update includes a new useAppContextFromSearch parameter for the Splunk REST API {{data/federated/provider/{federated_provider_name}}} endpoint. For more information about this new parameter, see "Federated search endpoint descriptions" in the REST API Reference.

• New flag for disabling Splunk Web's Custom REST Endpoints and Custom Mako Templates.

Two new flags have been added to the [feature:appserver_security] stanza of web-features.conf that admins can use to disable the following Splunk Web features:

1. Custom REST Endpoints on the Splunk Web (not Splunk Core) platform can be disabled by setting disable_custom_cherrypy_controllers to true (default: false).
2. Custom Mako Templates shipped by apps (not default templates shipped with Splunk Web) can be disabled by setting disable_custom_mako_templates to true (default: false).

While the behavior does not change in Splunk platform 10.4, this flag has been added to support a future deprecation effort for both of the above features.

• Modernize Field administration pages

Splunk field administration pages will update to the latest UI components and libraries, providing a modernized and consistent look and feel with the Splunk platform.

• Agent management

Application matching cache

Agent management caches the results of application-to-server-class matching, which reduces the processing time required when agents check in for deployment updates. In large-scale environments with many agents and server classes, this cache improves the performance of the agent management.

Server class configuration viewer

You can view the full configuration details of a server class directly in the agent management interface. You can use this view to verify server class configurations before making changes or to troubleshoot unexpected deployment behavior across your fleet of agents.

Application content previewer

You can preview the contents of a deployment application before distributing it to agents directly in the agent management interface. Use the content previewer to verify that an application contains the expected files and settings, which helps you identify configuration issues before deployment reaches your agents.

Removed parameters from serverclass.conf

The following parameters are removed from the serverclass.conf configuration file in version 10.4: packageTypesFilter, updaterRunningFilter.

• Data Management

The new Data Management app now serves as a hub to relevant experiences with a consistent look and feel. Whether you are configuring inputs, monitoring ingestion health, or managing federated connections or datasets, you can now do it all from one location.

• Independent client-side Transport Layer Security (TLS) certificate configuration for App Key Value Store (KV Store)

In response to public CA policy changes that drop the Client Authentication EKU from default TLS certificates, Splunk now supports independent KV Store client-side TLS configuration through a new [kvstoreSslClientConfig] stanza, allowing separate client and server certificates for KV Store mutual TLS.

Available in Splunk Enterprise 10.4 and applicable for Splunk Enterprise 9.4.10, 10.0.5, and 10.2.2, and Splunk Cloud 10.2.2510.8 and 10.0.2503.13

In 10.4 only: [kvstore] SSL settings are now evaluated per field; partial configurations previously ignored may now apply and should be reviewed before upgrade.

• Deprecating and removing default support for versions 1.0 and 1.1 of the TLS protocol for network connections between Splunk platform components

The Splunk platform is now turning off support by default for TLS 1.0 and TLS 1.1. These protocols remain available should customers require them for migration purposes, but will be completely removed in a future release. TLS 1.2 support remains unchanged and enabled by default alongside the newly-introduced TLS 1.3 support.

• Upgrade Splunk Python version from 3.9 to 3.13

Python 3.13 will become the default Python interpreter, with Py3.9 as fallback.

• Federated Search for Splunk Transparent Mode Support for IPv6 in Search Head Clusters

Federated Search for Splunk in transparent mode now supports bundle replication to any remote peer within a search head cluster, eliminating the need for direct network access to the remote search head captain. This enhancement enables support for IPv6 environments, such as Microsoft Azure, and configurations where a load balancer serves as the remote gateway.

• Role-based Access for Federated Search for Splunk REST APIs

Enhanced security controls are now available for Federated Search for Splunk REST API endpoints, introducing granular, role-based access control (RBAC). Previously, authenticated users could view all federated providers, indexes, and settings. This update shifts access logic to the handler level, ensuring that users only see the resources they are explicitly authorized to access.

Administrators can now enforce precise permissions for individual users, preventing unauthorized information disclosure and ensuring that sensitive infrastructure details remain protected. New specific capabilities have been introduced to manage these permissions effectively, replacing the need for broad, global access. These changes strengthen your security posture and support stricter internal governance, providing a more secure and compliant environment for your Federated Search operations.

The following new capabilities for Federated Search for Splunk are now available in this release:

• edit_federated_indexes
• edit_federated_providers
• list_federated_providers

For more information, see the Table of Splunk Enterprise capabilities in Securing the Splunk Platform.

• Indexing/Replication Separation

Introduces a new SmartStore-based architecture for Splunk Enterprise indexer clusters that decouples indexing from peer-to-peer replication. Instead of replicating buckets directly between indexers, data and metadata are stored in SmartStore as the system of record, allowing indexers to operate independently.

By removing peer-to-peer replication dependencies, this approach simplifies multisite deployments, improves operational resilience, and enables more flexible scaling of indexers.

• Upgrading the backend database for KV Store and KV Service to MongoDB 8.0

Splunk 10.4 release will not include old unsupported MongoDB versions from 4 to 6. If you’re running Splunk 9.x and below, please upgrade to Splunk 10.0 or Splunk 10.2 first as a direct update from MongoDB 4.x / Mongo 6.x to Mongo 8 is unsupported. If you’re on Splunk 10.x, no action is needed as the upgrade to MongoDB 8 will happen automatically with the Splunk upgrade.

• Run Splunk Enterprise without root or administrator privileges

Splunk Enterprise 10.4 enforces non-privileged execution across supported operating systems.

Linux: Running Splunk Enterprise as root is no longer supported. The --run-as-root option is honored only with splunk start, splunk stop, and splunk restart.

Windows — new installations: Splunk Enterprise must be configured to run as either a Local Service Account (LSA) or a Domain User Account (DUA) that is not a member of the local Administrators group. The Local System User (LSU) option is no longer available, and installation halts if a selected DUA belongs to the local Administrators group.

Windows — upgrades to 10.4: LSU configurations are migrated to an LSA with ACLs reset appropriately; LSA configurations are retained as-is; DUA configurations are retained provided the account is not in the local Administrators group, and the upgrade is halted otherwise until the DUA is removed from that group.

• Workload Management support for Kubernetes

Splunk Enterprise now supports workload management on Kubernetes-based deployments. A new workload management Basic mode lets you apply admission rules on systems such as Kubernetes where cgroups are not available.

You can use admission rules to prevent rogue or resource-intensive searches from interfering with critical workloads. See Use Workload Management on Kubernetes.

• Support for post-quantum cryptographic algorithms.

Splunk is releasing support for a set of algorithms based on Kyber, Dilithium, and SPHINCS+ to meet the requirements laid out in FIPS 203, 204, and 205 and protect customers from these future quantum threats to cryptography.

• TLS 1.3 support

The Splunk platform now supports version 1.3 of the TLS protocol, alongside TLS 1.2, for all public-facing connections, enhancing security with stronger encryption, eliminating outdated cipher suites, and delivering better performance and efficiency. TLS 1.3 will be enabled by default alongside TLS 1.2. For more information, see Introduction to securing the Splunk platform with TLS.

• Provider-based Search Targeting with Role-Based Access Control (RBAC) for Federated Search for Splunk

Enhanced Provider Control for Federated Search for Splunk

The new enhancements for Federated Search for Splunk in transparent mode provide administrators and end users with unprecedented control over how data is searched across distributed Splunk environments. These updates ensure that your search operations are more efficient, secure, and tailored to your specific organizational needs.

Federated Search for Splunk allows you to run searches across multiple remote Splunk deployments as if the data were local. In transparent mode, the federated search head acts as a seamless proxy and simplifies the user experience by abstracting the complexity of the underlying remote infrastructure.

1. Targeted provider routing

You can now direct federated searches to specific providers with greater precision:

• User-directed targeting: End users can now explicitly define which federated or remote providers they want to include in their searches, which means that resources are only utilized as necessary.
• Default provider lists: Administrators can configure a default list of providers. If a user does not specify a provider in their search string, the system automatically routes the search to these pre-defined, relevant providers, which maintains a streamlined workflow.

1. Role-Based Access Control (RBAC) for providers

Control over security and governance is now more granular. With the introduction of a new UI-based configuration, administrators can define access controls for individual providers. Now you can specify a default list of providers in the new Providers tab on a role to restrict which roles have the authority to search specific providers, so sensitive data remains accessible only to authorized users.

Benefits

• Optimized performance: By allowing users to target specific providers or defaulting to a curated list, you eliminate unnecessary broadcast traffic. This reduces system overhead and significantly improves search response times across your federated environment.
• Enhanced security and compliance: With new RBAC capabilities, you can enforce strict data governance. By limiting provider access based on user roles, you minimize the risk of unauthorized data exposure and ensure compliance with internal security policies.
• Improved user experience: These features simplify the search process by reducing complexity for end users, while providing administrators with the tools needed to manage a large-scale, multi-deployment environment effectively.

For more information, see:

• “Configure role-based access and search targeting for transparent mode federated providers” in the Federated Search manual.
• The srchFederatedProvidersAllowed and the srchFederatedProvidersDefault arguments for the authorization/roles/{name} endpoint, in “Federated search endpoint descriptions” in the REST API Reference.

Original source

Splunk Enterprise 10.2 was released on January 15, 2026.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known Issues for this release.

Planning to upgrade from an earlier version?

If you plan to upgrade to this version from an earlier version of Splunk Enterprise, read How to upgrade Splunk Enterprise in the Installation Manual for information you need to know before you upgrade.

See About upgrading: READ THIS FIRST for specific migration tips and information that might affect you when you upgrade.

The Deprecated and removed features topic lists computing platforms, browsers, and features for which Splunk has deprecated or removed support in this release.

What's New in 10.2

• Preview Update 2 feature: Field filters are now available by default (as of Splunk Enterprise version 10.2.2), and protect sensitive fields in searches that use the tstats command. Field filters let you limit access to confidential information by redacting or obfuscating fields in events within searches, with optional role-based exemptions. As of 10.2.2, field filters are visible for customer use by default, eliminating the need for manual configuration. Field filters now provide native support for the tstats command.

• Parquet format for data sent to Amazon S3 from Edge Processor: You can now choose to store data as parquet files when sending data from an Edge Processor to Amazon S3.

• Edge Processor on Splunk Enterprise operating system version support: Several OS versions are no longer supported (Amazon Linux 2, Centos 7, Debian 10 and 11, RHEL 8.0, SUSE Linux Enterprise 15.0, Ubuntu 20.04 LTS). New supported versions include Debian 12+, RHEL 9+, RockyLinux 9+, SUSE Linux Enterprise 15.0 SP6+, Ubuntu 24.04 LTS.

• Edge Processor on Splunk Enterprise supports JSON array format as input.

• Edge Processor monitoring dashboards: Updated UI to visualize metrics and health of Edge Processors.

• Updated systemd configuration instructions for graceful shutdown of Edge Processor instances.

• Support for OAuth2.0 for 3rd party and external applications.

• Improvements to Observability Metrics & Charts in Splunk Dashboard Studio.

• Splunk AI Assistant for SPL in the Search app is now available in Splunk Enterprise, providing natural language query generation, explanation, and translation.

• Removal of Node.js: Customers must update apps dependent on Node.js to bundle their own version.

• SPL2 language enhancements: Unified search and streaming language supporting SPL and SQL syntax, compatible with SPL.

• Federated provider names are now case-insensitive.

• SPL2 support for Dashboard Studio.

• Other Dashboard Studio enhancements.

• Ingest-Tier Scaling for high-throughput, scalable data ingestion.

• Bulk Data Movement between Indexes for efficient data reorganization.

• Enhanced visibility and management of OpenTelemetry Collector configurations.

• Agents lookup feature for improved performance in agent management UI.

• Agent management UI/UX enhancements.

• Destination configuration on agent management for S3 and file system destinations.

• Queued ad hoc search quotas to prevent unbounded queuing.

• TLS verification for inter-sidecar communication.

• Nascent sidecar ensures correct configuration on search head clusters.

• Audit Trail Log v2: structured audit log format compliant with CIM using JSON.

• Python 3.13 available on opt-in basis.

• KV store server version 8.0 available.

• Splunk Enterprise no longer runs as root by default.

• Monitoring Console Overview Dashboard (beta) redesign for improved user experience and efficiency.

Original source

Splunk Enterprise 10.2 was released on January 15, 2026.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known Issues for this release.

What's New in 10.2

• Preview Update 2 feature: Field filters are now available by default (as of Splunk Enterprise version 10.2.2), and protect sensitive fields in searches that use the tstats command.

  To protect your personal identifiable information (PII) and protected health information (PHI) data, and meet data privacy requirements such as GDPR or other privacy regulations, you can use field filters in the Splunk Platform to limit access to your sensitive data. Field filters let you limit access to confidential information by redacting or obfuscating fields in events within searches, with optional role-based exemptions. For more information about field filters, see Protect PII, PHI, and other sensitive data with field filters and Plan for field filters in your organization.

  With the Preview Update 2 release:

  • As of Splunk Enterprise version 10.2.2, field filters are visible for customer use by default, which eliminates the requirement for administrators to turn on the feature by configuring the limits.conf and web-features.conf files. Note: Not available in Splunk Enterprise versions 10.2.0 and 10.2.1.
  • Field filters now provide native support for the tstats command and the tstats command can now be used without restrictions on indexes protected by field filters.

  READ THIS FIRST: Should you deploy field filters in your organization? Field filters are a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but it might not be a good fit for everyone.

  If your organization uses downstream configurations, such as accelerated data models, Splunk Enterprise Security (ES) detections using those data models, and user-level search-time field extractions, make sure that you plan around the implications of field filters on those configurations before deploying field filters in your environment. See READ THIS: Downstream impact of field filters.

  If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview and mstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on indexes that have field filters.

• Parquet format for data sent to Amazon S3 from Edge Processor:

  When sending data from an Edge Processor to Amazon S3, you can now choose to store the data as parquet files. See Send data from Edge Processors to Amazon S3 for more information.

• Edge Processor on Splunk Enterprise operating system version support:

  The Splunk 10.2 Enterprise release contains an update to remediate several CVEs. In the binary build process older versions of the Golang and Go libraries were inadvertently included resulting in a breaking change which caused the following changes in the supported operating systems:

  • Amazon Linux 2 is no longer supported.
  • Centos 7 is no longer supported.
  • Debian 10 and 11 are no longer supported. Debian 12 and higher are now supported.
  • Red Hat Enterprise Linux (RHEL) 8.0 is no longer supported. RHEL 9.0 and higher is now supported.
  • RockyLinux 9 and higher is now supported.
  • SUSE Linux Enterprise 15.0 is no longer supported. SUSE Linux Enterprise 15.0 SP6 and higher is now supported.
  • Ubuntu 20.04 LTS is no longer supported. Ubuntu 24.04 LTS is now supported.

  Users running their data management control plane and edge processors on any non-supported operating systems must upgrade to a supported version of that operating system before upgrading their data management control plane to Splunk Enterprise 10.2 to avoid any data loss from their edge processors. Other Splunk Enterprise deployment components outside of your data management control plane are not impacted by this change. See Installation requirements in the Use Edge Processors for Splunk Enterprise manual for a list of supported operating systems.

• Edge Processor on Splunk Enterprise support for JSON array format as input:

  Edge Processor on Splunk Enterprise now supports JSON array format as input. This enhancement allows input to contain square brackets and objects to be separated by commas. For more information, see Get data into an Edge Processor using HTTP Event Collector.

• Edge Processor on Splunk Enterprise monitoring dashboards:

  The Edge Processor on Splunk Enterprise solution now includes an updated user-interface that allows you to quickly visualize the metrics and health of your Edge Processors. View the inbound and outbound data volume of each pipeline, and the logs of your Edge Processors, for different lengths of time. Use Edge Processor monitoring dashboards to understand the health of your Edge Processors. Visualize the flow of data into destination queues and check pipeline connections.

• Updated systemd configuration instructions:

  The instructions for configuring systemd to manage the underlying process of your Edge Processor instance has been updated to ensure more graceful shutdown procedures. Previously, when you ran the restart or stop commands from systemctl, the Edge Processor supervisor and systemd both sent terminating signals to the Edge Processor instance, causing the instance to terminate abruptly. You can now prevent this issue by specifying the KillMode=mixed setting in the systemd unit file. See the Install an instance and configure systemd section in Set up an Edge Processor for more information.

• Support for OAuth2.0 for 3rd party and external applications:

  Customers can easily and securely authenticate their 3rd party applications using the standardized processes and workflows offered through version 2 of the Open Authorization (OAuth 2.0) protocol. Administrators can now configure OAuth 2.0 for use with products like Data Analytics and User Behavior Analysis (UBA) tools to connect to Splunk platform through REST APIs, so end users can get data and insights, make decisions faster, and turn data into doing. See Configure an external Open Authorization 2.0 authorization server.

• Improvements to O11y Metrics & Charts in Splunk Dashboard Studio:

  Users can leverage observability application service map views in both published and exported dashboards, and incremental improvements and bug fixing to feature Splunk Observability Cloud metrics and charts in Splunk Dashboard Studio. See Add a Splunk Observability Cloud service map to Dashboard Studio dashboards.

• Splunk AI Assistant for SPL in the Search app is now available in Splunk Enterprise:

  Splunk AI Assistant for SPL is now available in the Search app for hybrid on-premises Splunk platform deployments. The Splunk AI Assistant helps users generate, explain, and translate SPL using natural language. This generative AI-powered experience is designed to support both new and advanced users by providing query suggestions, detailed explanations, and direct access to Splunk platform documentation. The AI assistant enables faster onboarding, improved productivity, and more effective investigations. The Splunk AI Assistant for SPL app version 1.3.2 or higher must be installed before you can use the AI Assistant in searches in Splunk Web. To learn more, see Use Splunk AI Assistant for SPL in the Search app.

• Remove Node.JS:

  Splunk previously announced deprecation of Node.js and is now removing it. Customers using apps dependent on Node.js will need to update their apps to bundle their own version of Node.js. Failure to do so may result in App/TA functionality degradation and unexpected behavior.

• SPL2:

  SPL2 extends the existing SPL language by incorporating several powerful features. These features simplify data access and analysis while also providing support for complex investigations and data management workflows. With SPL2, you can write searches using either SPL or SQL syntax. This simplifies learning and using the language, and adds consistency to the language. SPL2 is a unified search and streaming language, offering a single syntax for searching data in Splunk indexes, accessing federated data stores, and preparing data in-stream across various Splunk products. SPL2 is fully compatible, and can operate in parallel, with SPL. For information about what's new, known issues, and fixed issues, see SPL2 release notes in the SPL2 Overview manual. Note: Some versions of Linux are not supported by SPL2 in 10.2. See the SPL2 Known Issues.

• Federated provider names are now case-insensitive:

  As of this release, federated provider names are case-insensitive for Federated Search for Splunk. For example, say you have a provider named MyProvider and you try to create a new provider with a Provider name of myprovider. In this instance, Splunk software prevents you from creating the new provider until you choose a Provider name that is unique, regardless of alphabetical character case. Note: If you are upgrading from a previous version of the Splunk platform, this might be a breaking change. If you have two or more federated providers in your Splunk platform deployment with names that differ only by case (such as one named MyProvider and another named myprovider), you must change the duplicate provider names to unique strings. There are two ways to accomplish this: You can delete and recreate the federated providers with duplicate names. If you have access to the .conf files for your Splunk platform deployment, you can edit the duplicate federated provider names directly in federated.conf. You cannot edit federated provider names in Splunk Web. If you choose to not delete or replace duplicate provider names, Splunk software uses the first name that appears in federated.conf. For example, if the MyProvider stanza appears before the myprovider stanza in federated.conf, Splunk software references only the MyProvider stanza when it receives any version of the string "myprovider".

• SPL2 support for Dashboard Studio:

  In Dashboard Studio, you can use SPL2 data sources in dashboards by doing one of the following:

  • Create an SPL2 query from within a dashboard
  • Reference an existing view from an SPL2 module

  See Create search-based visualizations with SPL2.

• Other Dashboard Studio enhancements:

  See What's new in Dashboard Studio.

• Ingest-Tier Scaling:

  Ingest-Tier Scaling delivers high-throughput, scalable data ingestion for self-managed Splunk deployments, enabling customers to handle larger data volumes with improved resilience, operational efficiency, and clearer separation of ingest and indexing tiers. See Ingest-Tier Scaling.

• Bulk Data Movement between Indexes: Clustering:

  Bulk Data Move allows Splunk Enterprise users to efficiently reorganize indexes and move data between them using specific search criteria. Reclaim storage and manage sensitive information without requiring full index removal. Available only non-SmartStore clustered environments. See Bulk Data Move for indexer clusters.

• Effective configuration of OTel Collectors:

  We have enhanced the visibility and management of OpenTelemetry (OTel) Collector agent configurations within the Splunk platform. Now you can view the complete, active configuration for each OTel Collector agent that communicates using OpAMP (Open Agent Management Protocol). For more information, see Effective configuration of OTel Collectors.

• Agents lookup:

  To improve performance when managing a large number of agents, we have introduced the agents lookup feature for the agent management user interface. When enabled, this feature significantly reduces UI load times by retrieving agent data from a cached CSV lookup file generated by a saved search, instead of querying the index directly for every interaction. For more information, see Agents lookup.

• Agent management UI/UX enhancements:

  To improve the admin experience, we have enhanced the agent management user interface and user experience. Forwarders and OpenTelemetry management are now unified into a single-stop console, and an automated wizard has been introduced for simplified server class creation.

• Destination configuration on agent management:

  You can now configure S3 and file system destinations directly from agent management, and these changes will automatically be propagated to your connected agents. To maintain consistency, always configure destinations from agent management. This feature requires agent management version 10.2 or higher, while there is no version restriction for compatible agents. You can enable or disable this feature using the enableS3ConfigOnDs flag in the limits.conf file. For more information, see Create an S3 destination.

• Queued ad hoc search quotas:

  This feature introduces configurable limits on the number of ad hoc searches that Splunk software can queue at both the system level and the role level. These limits are designed to prevent unbounded queuing of ad hoc searches, which can negatively impact system performance and resource utilization. For more information, see Create and manage roles in Splunk Enterprise using authorize.conf.

• TLS verification for inter-sidecar communication:

  To enhance security, each sidecar uses a server data plane certificate when communicating with other sidecars through the direct port of the destination sidecar. Over a Transport Layer Security (TLS) connection on the direct port, the connecting sidecar verifies the certificate of the destination sidecar to ensure a trusted connection. For more information, see Inter-sidecar communication.

• Using Nascent to ensure correct configuration on search head clusters:

  The Nascent sidecar ensures that the etcd service runs with the correct configuration on each search head in the cluster. By managing the etcd cluster, it provides consistent configuration and service discovery throughout the cluster. This sidecar is necessary for the proper functioning of the Storage sidecar due to its dependency on etcd. For more information, see About the Nascent sidecar.

• Audit Trail Log v2: structured audit log format:

  The structured format of audit trail logs, also known as Audit Trail Log v2, complies with the Common Information Model (CIM). It uses JSON, which makes logs easier to parse and interpret. Audit Trail Log v2 includes comprehensive metadata, making it suitable for compliance purposes. This is the first phase in delivering Splunk Idea E-I-49. To learn about this format, see About structured audit trail logs.

• Python 3.13 is available on an opt-in basis:

  You can opt in to use Python 3.13 instead of Python 3.9. Splunk platform still uses Python 3.9 by default, but Splunk Web uses Python 3.13 only. To learn how to switch between Python versions, see Python compatibility in Splunk apps.

• KV store server version 8.0 is available:

  Upgrade to KV store server version 8.0. Splunk Enterprise 10.2 still supports KV store server version 7.0, but this server version will be removed in future versions of Splunk Enterprise. To learn how to upgrade your KV store server version, see Upgrade the KV store server version.

• Run Splunk Enterprise without the root option:

  Splunk Enterprise no longer runs as root by default. To start, stop, or restart Splunk Enterprise as root, append --run-as-root to the command.

• Monitoring Console Overview Dashboard (beta) redesign:

  The Overview (beta) dashboard has been updated for improved user experience and efficiency. The dashboard provides a summary of your deployment's most important metrics:

  • View a summary of your deployment's license entitlements and understand your resource usage with status indicators for each license entitlement metric.
  • Personalize your dashboard and choose the metrics that are most important to your users.
  • Access action items such as Refresh and Open in search in each metric's ellipses menu.
  • Provide feedback to the Splunk MC team using the Feedback button.
  • Monitor forwarders and get alerts when forwarders are missing.

  To learn more about the Overview (beta) dashboard, see Overview Dashboard.

Original source

Splunk Enterprise 10.0 was released on July 28, 2025.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known Issues for this release.

Planning to upgrade from an earlier version?

If you plan to upgrade to this version from an earlier version of Splunk Enterprise, read How to upgrade Splunk Enterprise in the Installation Manual for information you need to know before you upgrade.

See About upgrading: READ THIS FIRST for specific migration tips and information that might affect you when you upgrade.

The Deprecated and removed features topic lists computing platforms, browsers, and features for which Splunk has deprecated or removed support in this release.

What's New in 10.0

• Edge Processor service: The Edge Processor solution is a service hosted within your Splunk Enterprise deployment designed to help you manage data ingestion within your network boundaries. Use the Edge Processor solution to filter, mask, and transform your data close to its source before routing the processed data to external environments. For more information, see About the Edge Processor solution.

• Updated support for Federal Information Processing Standards (FIPS): Splunk Enterprise now has updated support for the FIPS Publication #140-2 module and new support for Publication #140-3 module. These modules let you run Splunk Enterprise in FIPS mode to comply with these guidelines. The updated FIPS 140-2 module that comes with Splunk Enterprise 10.0 is valid until March of 2026. This gives you time to move over to the new FIPS 140-3 module after you upgrade both Splunk Enterprise components and your forwarding tier infrastructure to version 10. For more information about Splunk Enterprise and FIPS, see Secure Splunk Enterprise with FIPS. For information about upgrading FIPS in Splunk Enterprise, see Best practice for maintaining compliance with FIPS and Common Criteria in your Splunk Enterprise environment.

• Support for encryption with mutual transport layer security (mTLS): Splunk Enterprise now supports the configuration of mTLS for encryption of network connections between Splunk Enterprise instances and services.

• OpenSSL version 3.0 support: Splunk Enterprise version 10.0 brings support for OpenSSL version 3.0, which replaces the deprecated OpenSSL version 1.0.2. Additionally, the software is bound to version 3.9 of the Python runtime environment for secure connections to services and APIs.

• Fine-grained access to search knowledge objects: Splunk admins now have improved options for assigning permissions to roles for access to knowledge objects. Three new capabilities grant admins increased flexibility in assigning access to the objects and replace the admin_all_objects capability, which was the only option available previously. For more information on configuring fine-grained access for search knowledge objects, see Configure roles for fine-grained management of saved search objects, owners, and properties.

• Sidecars: Sidecars are processes that run alongside the splunkd process to fulfill specific functions. They support introducing new features to the Splunk platform. For example, several sidecars support enhanced data management in the on-premises environment. Sidecars affect your Splunk Enterprise environment by introducing multiple sidecar processes. Process names of sidecars don't include a splunk prefix. To learn more about sidecars, see About Splunk sidecars.

• Dashboards Trusted Domains List: Admins can add and remove domains using the Dashboards Trusted Domains List page. To navigate to this page, in the Splunk bar, select Settings > Server settings > Dashboards Trusted Domains List. To learn more, see Configure Dashboards Trusted Domains List.

• Dashboards in the Audit Trail app: Using the Audit Trail app, you can quickly gain insights on security, compliance, and the operation of a Splunk platform instance. The dashboards help you monitor user activities and changes of knowledge objects in real time, based on data from the audit index, index=_audit. If you notice any issues to troubleshoot or activities to investigate, you can get more details by searching the audit log. It is a good practice to begin an audit of Splunk platform activity by reviewing the Audit Trail dashboards. To learn more about the Audit Trail dashboards, see Auditing activities in a Splunk platform instance.

• Support for the savedsearch command in standard mode federated searches: You can now use the savedsearch command to run federated searches over remote saved search datasets located on standard mode federated providers. In addition, you can use the savedsearch command's string substitution replacement syntax to replace certain strings in the remote saved search with strings of your design, if the remote saved search string contains replacement placeholder terms such as $replace_me$. Note: This feature will be a breaking change for users of the savedsearch command, if they use savedsearch to reference local searches with names that begin with the string federated:. With this release, the savedsearch command will treat any search referencing a saved search name that begins with federated: as a federated search. See the following topics for more information: Run federated searches over remote Splunk platform deployments in Federated Search. The savedsearch reference topic in Search Reference.

• Expanded SPL support for standard mode searches in Federated Search for Splunk: Support has been added for the following commands in standard mode federated searches for Federated Search for Splunk: mcollect sendalert sendemail These commands can now run locally on the federated search head. See SPL commands that run on the federated search head in standard mode.

• Email domains enhancement: A new enhancement for the Email Domains setting under Server settings in Splunk Web lets administrators specify whether to allow or deny all email domains, or use email domains in a comma-separated list. The Email Domains setting restricts the email domains to which alert emails can be sent and prevents users from sending email alerts with search results to any domain, which is a security risk. If you don't want to use Splunk Web to manage email domains, you can configure the allowedDomainList setting in the [email] stanza in the alert_actions.conf file instead.

• OAuth 2.0 support for email server authentication: Splunk Enterprise now supports OAuth 2.0 for SMTP server authentication. This release adds support for Microsoft Exchange Server. For Gmail SMTP server, you can use a Google app password instead of an account password with simple authentication (username/password). See Configure email notification for Splunk Enterprise

• Splunk Enterprise Python 3.9: Python version 3.7 has been removed from Splunk Enterprise 10.0 and higher. Python 3.9 is the only interpreter available in this release. Confirm that all apps and add-ons are on the latest version and compatible with Python 3.9, otherwise those applications might break or not function properly with Splunk Enterprise.

• Dashboard Studio enhancements: See What's new in Dashboard Studio.

• Preview feature: Field filters now support the typeahead and walklex commands: In previous releases of field filters, the typeahead and walklex commands were restricted commands that the Splunk platform turned off by default on indexes with field filters. As of this release, these commands are no longer restricted. For more information about field filters, see Protect PII, PHI, and other sensitive data with field filters. READ THIS FIRST: Should you deploy field filters in your organization? Field filters are a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but they might not be a good fit for everyone. If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview, mstats, and tstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on any indexes if field filters are in use in the Securing Splunk platform manual.

• Preview feature: Field filters are now first in the sequence of search-time operations, which has implications for downstream operations: Field filters have moved to first in the sequence of search-time operations, and are no longer processed fourth in the sequence as in previous releases. Because field filters are processed before all other operations in the sequence, downstream operations that depend on certain field values might break when expected field values are filtered by field filters. See The sequence of search-time operations in the Splunk Platform Knowledge Manager Manual. If your organization uses the Splunk Common Information Model (CIM), and field filters on the Splunk platform to protect sensitive fields, you should also understand the downstream impact of field filters on data model acceleration (DMA). For more information about the impact of field filters on DMA, see Plan for field filters in your organization in the Securing Splunk Platform in the Securing Splunk platform manual.

• Dynamic limit for scheduled searches: Splunk Enterprise 10.0 introduces the dynamic_max_searches_perc setting. This setting allows the search scheduler to automatically adjust the scheduled search concurrency limit (max_searches_perc) based on the ad hoc and scheduled search workload. This feature can reduce search latency, minimize skipped searches, and help you use search capacity more efficiently between ad hoc and scheduled searches. See Dynamically manage scheduled search concurrency limits.

• Effective configuration: This feature lets you view the actual configuration installed on your forwarders without logging into the machines or running btool. This means you no longer need to rely on other teams to access configuration details. With this feature, you can see the real, active settings applied on forwarders, including all parameter changes in .conf files. It gives you a complete picture of the configuration currently in use. You can download the effective configuration files and open them in a text editor for further analysis. See View configurations installed on your forwarders.

• Bulk Data Move: Bulk Data Move allows Splunk Enterprise users to efficiently reorganize indexes and move data between them using specific search criteria. Easily reclaim storage and manage sensitive information with precision, avoiding the friction of full index removal. Available for Standalone (single instance) deployments only. See Split indexed data in the Manage Indexes and Indexer Clusters manual.

• OpenTelemetry Collectors: This feature allows you to view information about OTel Collectors you manage, helping you monitor status of your agents in one place. You'll see a list of registered OTel Collectors in a table view. You can view more details along with key attributes by selecting an individual agent. This view-only functionality supports better visibility into how your data collection components are operating. See Monitoring the status of OpenTelemetry Collectors in Splunk Enterprise.

• Observability metrics in Dashboard Studio: You can create charts in Dashboard Studio that are based on observability metrics or import an existing Splunk Observability Cloud chart into Dashboard Studio. You can also filter observability-based metrics charts by dimension to look at something more granularly. See Splunk Observability Cloud metrics in Splunk Cloud Platform.

• Preview observability data in the Search app: In a new Related Content panel, you can see previews of Splunk Observability Cloud data and context that are related to an event you are investigating in the Search & Reporting application. See Preview observability data in the Related Content panel.

• View an observability service map in Dashboard Studio dashboards: You can add a service map for services monitored in Splunk Observability Cloud into Dashboard Studio. A service map allows you to see dependencies and connections among your instrumented and inferred services in APM at a glance on the dashboard of your choice in Splunk Cloud Platform. You can then identify performance bottlenecks and error propagation side-by-side with your other charts and graphs. See Add a Splunk Observability Cloud service map to Dashboard Studio dashboards.

• SPL2 module permissions: When you create a module you are automatically given execute, read, and write permissions on that module. Previously, only users with the admin and power roles were granted these permissions on modules. Permissions for the module owner can't be revoked. You can grant or revoke permissions on the modules that you create. Module permissions are set using the REST API endpoints. See Modify permissions for modules in the Splunk Enterprise Admin Manual.

• Deprecated version 1.0 endpoints for the Search API are now deactivated by default: Select version 1.0 endpoints for the Search API have been deprecated and deactivated, and will be removed in a future release. Customers and app developers should upgrade usage of these deactivated endpoints to the new API version, Search API version 2.0. These new Semantic Versioned Rest API endpoints for search improve platform contracts and resiliency to platform updates. If your organization has business-critical apps that still need to use the deactivated endpoints, you can turn them on for a limited time as a temporary fix. See Semantic API versioning in the REST API Reference Manual.

• Sunsetting of the Upgrade Readiness App: Splunk is ending its support of the Upgrade Readiness App. It will no longer be updated and has been removed from this version of Splunk Enterprise. For more information, see Sunsetting of the Upgrade Readiness App.

• Updated alerts page: The alerts page is updated for usability and accessibility. Note: If you configure a custom alert action with HTML, ensure the HTML doesn't include unsupported or malformed elements. Update your HTML to match the supported custom elements for Splunk Web. For more information, see Create the configuration UI for a custom alert actionopen_in_new.

• Favorite knowledge objects: Users can now add and remove reports from favorites. Favorites make insights discovery and accessing knowledge objects, such as reports, easier and faster.

• Agent management can upgrade universal forwarders (Splunk idea EID-I-70open_in_new): With this feature, you can upgrade universal forwarders by installing the Remote Upgrader with elevated privileges just once. After this one-time setup, performed either manually or with automation tools, all future upgrades of universal forwarders can be managed centrally through the agent management (in versions 10.0 and higher of Splunk Enterprise) or deployment server (in versions 9.x of Splunk Enterprise), eliminating the need for repeated manual intervention. To learn more about the Remote Upgrader tool, see About the Splunk Remote Upgrader for Linux Universal Forwarders.

• Ingest Actions Live Capture on search heads: The new Live Capture capability on search heads improves the accuracy of event previews in Ingest Actions. A Live Capture tab in the ruleset editor retrieves real-time sample events from up to 10 connected indexers or heavyweight forwarders at once, using sampling logic similar to Deployment Server and Deployment Client. This feature ensures that event previews reflect actual ingest time data, which addresses issues caused by post ingest changes such as source type renaming. It also improves rule accuracy, user confidence, and support efficiency. Live Capture is available in both Splunk Cloud and Splunk Enterprise deployments and does not support data capture from non-clustered indexers. Live Capture is not recommended for sensitive data, as it does not enforce Role Based Access Control (RBAC) on indexes. Regardless of RBAC restrictions, anyone using Ingest Actions and Live Capture can view events going into an index that match a certain source type.

Original source

Splunk Enterprise 9.4.3 was released on June 5, 2025. It resolves the issues described in Fixed issues.

• Splunk Enterprise versions 9.4 and higher no longer support KV store server version 4.2.
• Upgrade to KV store server version 7.0 for continued support and security, and to comply with Splunk Support Policy open_in_new. For more details, see Splunk Support Policy open_in_new. Your deployment automatically upgrades your KV store during your upgrade to Splunk Enterprise 9.4. This new server version includes security enhancements and improves the performance of your KV store. See Upgrade the KV store server version open_in_new in the Admin manual to plan your upgrade.

Original source

Splunk Enterprise 9.4 was released on December 16, 2024.
If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.
For system requirements information, see the Installation Manual.
Before proceeding, review the Known Issues for this release.

Planning to upgrade from an earlier version?
If you plan to upgrade to this version from an earlier version of Splunk Enterprise, read How to upgrade Splunk Enterprise in the Installation Manual for information you need to know before you upgrade.
See About upgrading: READ THIS FIRST for specific migration tips and information that might affect you when you upgrade.
The Deprecated and removed features topic lists computing platforms, browsers, and features for which Splunk has deprecated or removed support in this release.

What's New in 9.4

• Deployment server version 9.4: Deployment Server provides a centralized location and user-interface to manage, maintain, and troubleshoot all types of Splunk agents, such as the Universal Forwarder and the Heavy Forwarder. Deployment Server 9.4.0 provides the following new capabilities: Overview of the health and status of your agents, A new UI with a shorter load time and updated user experience, Accessibility compliance
• Upgrade KV store server version from 4.2 to 7.0: Splunk Enterprise versions 9.4 and higher work best with KV store server version 7.0. Your deployment automatically upgrades your KV store during your upgrade to Splunk Enterprise 9.4. This new server version includes security enhancements and improves the performance of your KV store. See Upgrade the KV store server version in the Admin manual to plan your upgrade.
• Stats V1 removal: Version 1 of the stats command has been removed and replaced with version 2 of the stats command.
• Enhancement to the foreach command: A new auto_collections mode has been added the foreach command. The auto_collections mode dynamically iterates over a JSON array or multivalue field depending on which element is present in the search. See foreach in the Search Reference.
• Federated Search for Splunk: Metric indexes now supported as a new dataset type for federated searches: With this release, Federated Search for Splunk adds a new dataset type for standard mode federated searches: metric indexes. You can now run federated searches over metric index datasets. Additional error handling has been added to ensure that you apply event generating commands to event index datasets and apply metric generating commands to metric index datasets. Note: This is a breaking change for previous federated searches of metric indexes. If you are upgrading the federated search head on your local deployment from a previous version of the Splunk platform, and you have defined federated indexes on that federated search head that map to index datasets which contain metric data, you must replace those federated indexes with new federated indexes that map to metric index datasets. This update does not require you to make any changes to the remote deployment. For more information about defining federated indexes that map to metric index datasets, see Map a federated index to a remote Splunk dataset in Federated Search. For more information about writing federated searches for metric index datasets, see Run federated searches over remote Splunk platform deployments in Federated Search.
• Federated Search for Splunk: Support for eventcount across Standard and Transparent mode: The eventcount command is now supported by Federated Search for Splunk. This support includes the option to have eventcount return event counts for indexes on remote Splunk platform deployments that are designated as federated providers. eventcount search results now include a provider column that identifies the federated providers that listed indexes belong to. For more information, see eventcount in the Search Reference.
• Federated Search for Splunk: Standard mode federated search support for the mcatalog command: The mcatalog command is now supported for standard mode federated searches. For more information, see the following topics: Run federated searches over remote Splunk platform deployments, in Federated Search. mcatalog, in the Search Reference.
• Internal Library Settings: The Internal Library Settings page is removed. Deprecated libraries and unsupported hotlinked imports are restricted, and Splunk Cloud Platform no longer offers a self-service option to use them. For more information about Internal Library Settings, see Control access to jQuery and other internal librariesopen_in_new in the jQuery Upgrade Readiness manual.
• Dashboard Studio enhancements: See What's new in Dashboard Studio.
• SPL2-based application development: This version of Splunk Enterprise supports SPL2 via API, to help admins create powerful apps to gain more control over their ecosystem while allowing developers massive flexibility for the custom apps they can build. Admins and developers can use the API or the Splunk Extension for VS Code to create their apps. Admins and developers can ship SPL2 module files that define custom functions, views, data types, and more to curate resources within their application for users. Users can leverage these resources in the Splunk search bar to create dashboards and reports, by writing single-statement SPL2 searches. See Create SPL2-based appsopen_in_new in the Splunk Developer Guide on dev.splunk.com Admins can use SPL2 views with run-as-owner permissions. This applies special permissions on modules to execute views under a more privileged context, allowing multiple roles to access sensitive data with different levels of custom data masking. See Manage SPL2-based apps in the Splunk Enterprise Admin Manual.
• Eval function enhancements for data type conversion and type testing: You can use the following new eval data type conversion functions to manipulate values in eval searches. toarray to convert a value to an array value. tobool to convert a value to a boolean value. todouble to convert a value to a double value. toint to convert a value to an integer value. tomv to convert a value to a multivalue. toobject to convert a value to the equivalent object value of the field, if any. json_entries to convert a value to an array of JSON objects with key and value fields. You can use the following new eval functions to return information about values in eval searches. isarray to test whether a value is an array value. isdouble to test whether a value is a double value. ismv to test whether a value is a multivalue. isobjectto test whether a value is an object. json_has_key_exact to test whether a JSON key is in a JSON object. For more information, see Common eval functions in the Splunk Enterprise Search Reference.
• Eliminate SHC out-of-sync issues: Search head cluster (SHC) replication has been improved to reduce out-of-sync errors. Previously, large CSV lookup files that exceeded the 5GB file size limit could block replication and cause cluster members to go out of sync, often requiring a "destructive resync" to remediate. Now if a CSV lookup exceeds the lookup file size limit, the cluster automatically quarantines the lookup on the search head on which it is generated, without blocking replication of other objects. The splunkd health report shows the number of quarantined lookups and admins can run a search to get details on these lookups for remediation. For more information, see Quarantining large CSV lookup files in search head clusters in the Knowledge Manager Manual.
• Workload management - Support for cgroups version 2: Workload management now supports Linux operating systems that use cgroups version 2. Splunk Enterprise 9.4 is enabled by default to automatically detect and switch to cgroups v2. For more information, see Configure cgroups v2 in Splunk Enterprise in Workload Management.
• Support for persistent queues for Output queues with Splunk to Splunk (S2S) protocol: Ability to leverage persistent queues on output queues to automatically fallback to disk and recover, in case of destination or network failure. Use cases are for collection purpose for remote Splunk deployment (intermittent connectivity or need to survive a long network outage) and/or cloning data to one or multiple Splunk destinations, via S2S protocol, with no data loss and minimal impact in case of destination unavailability.

Original source