Missing Deployment Timestamp in Operate API for Process Definitions

Camunda 8 Topics
,
1

Hi Camunda Team and Community,

I’d like to raise an issue regarding missing deployment metadata in the Camunda 8 Operate API, specifically the deployment timestamp for process definitions.

Current Situation

In Camunda 7, Cockpit provided a dedicated deployment section where we could easily see when each process definition was deployed. This was valuable for auditing, troubleshooting, and understanding the deployment history of our processes.

In Camunda 8, when using the Operate API endpoint /v1/process-definitions/search, the response only includes:

  • key

  • name

  • version

  • bpmnProcessId

  • tenantId

The deployment timestamp is not included.

Example Response:

{ "items": [ { "key": 2251799814670485, "name": "TEST BPMN", "version": 1, "bpmnProcessId": "test_bpmn_v3", "tenantId": "<default>" } ] }

Use Case

Knowing when a process definition was deployed is important for:

  • Audit trails - tracking when changes were made to production and also verifying deployment quickly

  • Troubleshooting - correlating process behavior with deployment times

  • Compliance - maintaining deployment history records

  • DevOps workflows - verifying deployment success and timing

Question

  1. Is there a way to retrieve deployment timestamps through the Operate API that I’m missing?

  2. If not, is this feature planned for future releases?

  3. For Self-Managed installations, which Elasticsearch/OpenSearch indices contain this information?

Would appreciate any guidance or confirmation if this is a known limitation that might be addressed in future releases.

Thanks in advance,

Jignesh Pithava

2

Hi @pithvajignesh,

Thank you for raising this important question about deployment timestamps in the Camunda 8 Operate API. I can confirm that this is indeed a current limitation.

Current Status

You are correct that the /v1/process-definitions/search endpoint in the Camunda 8 Operate API does not include deployment timestamps in the response. The API currently only returns:

  • key
  • name
  • version
  • bpmnProcessId
  • tenantId

This is a notable difference from Camunda 7’s Cockpit, which provided deployment metadata including timestamps.

Answers to Your Questions

  1. Is there a way to retrieve deployment timestamps through the Operate API?

    • Unfortunately, no. The current Operate API does not expose deployment timestamps as part of the process definition metadata.

  2. Is this feature planned for future releases?

    • Based on my research, there doesn’t appear to be an existing GitHub issue or confirmed roadmap item for this specific feature yet.

  3. For Self-Managed installations, which Elasticsearch/OpenSearch indices contain this information?

    • The deployment information is stored in the Zeebe exporter indices (typically prefixed with zeebe-record), specifically in the zeebe-record_deployment_* indices. These indices contain the raw deployment records from Zeebe, which may include timestamp information, though the exact field structure isn’t fully documented.
    • You could inspect these indices directly in your Elasticsearch/OpenSearch instance to see if deployment timestamps are available at the data layer.

Recommended Next Steps

Since this appears to be a legitimate gap in the API functionality, I’d recommend:

  1. File a feature request on the Camunda GitHub repository with your specific use case
  2. Alternatively, submit it to the Camunda public roadmap

Your use cases (audit trails, troubleshooting, compliance, DevOps workflows) are compelling reasons why this metadata should be available through the API.

Temporary Workaround

For Self-Managed installations, you might be able to query the Elasticsearch/OpenSearch indices directly to retrieve deployment timestamps, though this would require additional implementation work on your side.

Would you like me to help you draft a feature request for the GitHub repository with the details you’ve provided?

References:

3

(post deleted by author)

4

Yes please draft a feature request for the GitHub repository

5

GitHub Feature Request Template

Here’s a draft feature request you can submit to the Camunda GitHub repository:

Title: Add deployment timestamp to Operate API process definition metadata

Labels: type:feature-request, component:operate

Description:

Problem Statement

The Camunda 8 Operate API /v1/process-definitions/search endpoint currently does not include deployment timestamps in the response metadata. This information was available in Camunda 7’s Cockpit and is essential for various operational use cases.

Current Behavior

The API response only includes:

{
  "items": [
    {
      "key": 2251799814670485,
      "name": "TEST BPMN",
      "version": 1,
      "bpmnProcessId": "test_bpmn_v3",
      "tenantId": "<default>"
    }
  ]
}

Desired Behavior

Include deployment timestamp in the response:

{
  "items": [
    {
      "key": 2251799814670485,
      "name": "TEST BPMN",
      "version": 1,
      "bpmnProcessId": "test_bpmn_v3",
      "tenantId": "<default>",
      "deploymentTimestamp": "2024-01-15T10:30:00.000Z"
    }
  ]
}

Use Cases

  • Audit trails: Track when changes were deployed to production
  • Troubleshooting: Correlate process behavior with deployment times
  • Compliance: Maintain deployment history records for regulatory requirements
  • DevOps workflows: Verify deployment success and timing
  • Change management: Understanding deployment sequences and rollback scenarios

Additional Context

  • This functionality was available in Camunda 7 Cockpit
  • The deployment data likely exists in the underlying zeebe-record_deployment_* Elasticsearch/OpenSearch indices
  • Both SaaS and Self-Managed users would benefit from this enhancement

Environment

  • Camunda Version: 8.x (affects all versions)
  • Component: Operate API
  • Deployment: Both SaaS and Self-Managed

Feel free to modify this template based on your specific needs or add any additional context that might be relevant to your use case. You can submit this at: Sign in to GitHub · GitHub

Let me know if you’d like me to adjust anything in the template!