Skip to main content


Splunk Lantern

Continuous delivery build duration

You might need to measure the duration of continuous delivery when doing the following:


In order to execute this procedure in your environment, the following data, services, or apps are required:

The plug-in for Jenkins is not supported by Splunk.


Your team has recently implemented a CI/CD pipeline. The flurry of production changes inherent in this model can be overwhelming. As an engineering manager, you want to use Splunk ITSI to quickly get see how long, in minutes, your build take.

To optimize the search shown below, you should specify an index and a time range. 

  1. Check that you have correctly installed and configured an application performance monitoring add-on.
  2. Run the following search:
    (tag=continuous_delivery AND tag=test_system)
    | mvexpand lifecycle_id 
    | eval avg_duration=duration/(1000 * 60) 
    | timechart span=5min avg(avg_duration)

Search explanation

The table provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.

Splunk Search Explanation

(tag=continuous_delivery AND tag=test_system)

Search for events that are tagged as continuous_delivery or build_system events.

| mvexpand lifecycle_id 

Create a new event for each value found in the lifecycle_id field.

| eval avg_duration=duration/(1000 * 60) 

Calculate the time each build took, in minutes.

| timechart span=5min avg(avg_duration)

Graph the average duration in 5 minute increments.


For more granular results with scripted inputs, you can increase the frequency at which the input runs using the interval setting in inputs.conf. Running the input more frequently consumes more storage, and running it less frequently uses less, which can affect license consumption. The default interval is 60 seconds. 

Use this search to track changes in your environment to complete the following tasks as needed:

  • Maintain security compliance and allow for a detailed lifecycle of a host or application.
  • Tie change requests to different departments.
  • Configure the system to send alerts when changes fail, are outside the normal window, and respond to unauthorized changes.
  • Address issues from your multi-stage build plans and configure the system to send notifications, alerts, and create tickets to resolve issues in real-time.
  • Was this article helpful?