This is the most accurate and recommended method for tracking Deploy Frequency in Allstacks.

In this setup, customers implement the custom Allstacks deployment webhook to notify Allstacks whenever a production deployment occurs.

Important

Standard CI/CD webhooks are often not sufficient for DORA tracking because they may not include all the deployment metadata Allstacks requires, such as:

• Job start time

• Job duration

• Deployment status

• Commit SHA

• Deployment identifier

• Service identifier

Because of this, a custom webhook implementation is required to ensure DORA metrics are accurate and complete.

Example

A deployment pipeline in tools such as Jenkins or GitHub Actions sends a custom webhook payload to Allstacks after every successful production deployment.

This payload contains the deployment metadata required for accurate DORA metric calculations.

Allstacks then uses this deployment data to calculate:

• Deploy Frequency

• Lead Time for Changes

• Change Failure Rate

Advanced Filters

Advanced filters can narrow deployments to only the deploys relevant to a specific team, application, or service.

Example:

• Environment = Production

• Service = Payments API

This prevents unrelated deployments from being counted.

Use this option if:

• You do not have a build tool connected

• You do not want to implement webhooks

• Your organization tracks releases through tickets

In this method, Allstacks measures Deploy Frequency based on when release tickets are completed.

Example

A customer uses Jira release tickets such as:

• REL-101 → April Release

• REL-102 → Hotfix Deployment

• REL-103 → Mobile App Production Release

When those tickets move to “Done,” Allstacks counts them as deployments.

Advanced Filters

Advanced filters should be configured to include ONLY tickets that represent production releases.

Example:

• Issue Type = Release

• OR Label = Production Deployment

This prevents standard development tickets from being counted as deployments.

Tradeoff

This method is less accurate because:

• Tickets may close after deployment

• One ticket may represent multiple deploys

• Some deploys may occur without tickets

Use this option if you want to use successful production deployment jobs from your CI/CD system as a proxy for deployments.

This option works best only when:

• You are using a supported build tool

• Your deployment pipeline is very simple

• One deployment job equals one production deployment

Example

In Jenkins:

• deploy-prod → SUCCESS

• deploy-prod → FAILED

• deploy-prod → SUCCESS

Allstacks may interpret:

• 2 successful production deploys

• 1 failed production deploy

Tradeoff

This method may become inaccurate if:

• Multiple jobs make up one deployment

• Deployments happen outside the CI/CD platform

• The deployment workflow is complex

This is the recommended and most accurate DORA method.

Customers use the custom Allstacks deployment webhook to notify Allstacks whenever a production deployment succeeds.

Important

Standard CI/CD webhooks often do not provide enough deployment metadata for accurate DORA calculations. A custom webhook implementation is required to ensure the deployment payload contains all required fields.

This approach allows Allstacks to support virtually any deployment process without requiring new native integrations.

Example

Developer commits:

• Commit A → Monday 9 AM

• Commit B → Monday 1 PM

Deployment webhook sent:

• Wednesday 9 AM

Allstacks calculates:

• Commit A Lead Time = 48 hours

• Commit B Lead Time = 44 hours

Average Lead Time:

• 46 hours

Why this is recommended

• Provides true DORA Lead Time

• Measures actual time from commit to production

• Supports complex deployment workflows

Use this option if:

• You do not have deployment tooling connected

• You cannot implement webhooks

This measures how long tickets take to move from:

• First “In Progress”
  to

• First “Completed”

Example

Ticket:

• Started Monday

• Completed Thursday

Cycle Time:

• 3 days

Advanced Filters

Advanced filters can exclude ticket types that should not be included in engineering delivery metrics.

Example:
Exclude:

• Subtasks

• QA/Test Case tickets

• Documentation work

Include:

• Stories

• Bugs

• Engineering work items

Tradeoff

This is not true DORA Lead Time because:

• It measures ticket workflow time

• It does not confirm code reached production

This is a legacy DORA implementation used by older customers already configured with the previous Allstacks DORA setup.

If you are implementing DORA for the first time in Allstacks, this option should not be used.

This still measures:

• Time from commit creation to successful production deployment

However, it relies on older integration methods instead of the recommended webhook-based deployment tracking.

This measures how long it takes to resolve production failures or service-impacting incidents.

The metric measures:

• Ticket Creation Time
  to

• Ticket Completion Time

for tickets identified as change failures.

Example

Incident:

• Created Monday 10 AM

• Resolved Monday 2 PM

Time to Restore Service:

• 4 hours

Advanced Filters

Advanced filters define what qualifies as a production failure.

Example:

• Priority = P1 or P2

• “Caused in Release” field is populated

This prevents unrelated incidents from affecting the metric.

This is the recommended DORA method for measuring Change Failure Rate.

When webhook-based Deploy Frequency is enabled, the number of successful production deploys reported through the custom Allstacks webhook is used as the denominator.

Formula:
Failures ÷ Deployments

Example

Deployments reported through webhooks:

• 100 production deploys

Production incidents:

• 5 release-related failures

Change Failure Rate:

• 5%

Advanced Filters

Advanced filters define which incidents count as deployment failures.

Example:

• Severity = P1 or P2

• Caused by Release = Yes

Important

If deployment webhooks are incomplete or missing required deployment metadata, deployment counts may become inaccurate, directly impacting Change Failure Rate calculations.

This option can be used when customers are not using webhook-based deployment tracking in Allstacks.

Instead of using deployments reported through custom webhooks, the denominator for Change Failure Rate is derived from the selected non-webhook Deploy Frequency method, such as:

• Ticket Completion

• Build Success Rate

Formula:
Failures ÷ Deployments

Example — Ticket Completion Method

Deployments identified through completed Release tickets:

• 20 completed Release tickets

Production incidents:

• 2 release-related failures

Change Failure Rate:

• 10%

Example — Build Success Rate Method

Production deployment jobs:

• 50 successful deploy jobs

Production incidents:

• 5 release-related failures

Change Failure Rate:

• 10%

Advanced Filters

Advanced filters define which incidents count as deployment failures.

Example:

• Severity = P1 or P2

• Caused by Release = Yes

Advanced filters should also be carefully configured on the deployment side to ensure only true production releases are counted.

Important

Because this method does not use direct deployment webhook reporting, metric accuracy depends heavily on:

• Consistent release ticket management

• Proper deployment job naming

• Accurate filtering configuration

If releases are not consistently tracked, deployment counts — and therefore Change Failure Rate calculations — may be inaccurate.

Use this option if:

• Deployments happen infrequently

• Build systems are unavailable

• Webhooks cannot be implemented

This method does not calculate a percentage. Instead, it simply counts production failures.

Example

This month:

• 7 production incidents created

Displayed Metric:

• 7 failures

Advanced Filters

Advanced filters define what type of tickets represent production failures.

Example:

• Priority = P1 or P2

• “Caused in Release” field is populated

Tradeoff

This is not a true Change Failure Rate because deployments are not included in the calculation.