# Measure the time from environment request to working deployment

Account creation speed misses much of the work. Track when a team can deploy, diagnose and operate a real service through the supported path.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Define the end of onboarding

A newly created subscription with no deployment identity or network access is not ready for an application team. Define readiness using a representative service and its required dependencies.

Measure elapsed time from an accepted environment request to a successful deployment and a verified operational check. Separate waiting for required business information from delays inside the platform process.

Keep manual interventions visible. A fast result achieved by an administrator making undocumented changes is not repeatable onboarding.

## Measure friction in the supported path

Track deployment failures caused by baseline conflicts, missing access and unclear configuration. Classify the cause so application defects do not obscure platform problems.

Record how long teams wait for policy clarification or an approved exception. Repeated questions about the same control suggest that its documentation or interface needs improvement.

Do not use exception count alone as a quality score. A low count can mean the baseline works well, or that teams have stopped using the supported process.

## Verify operational coverage

Check that workload environments have accountable owners, required audit collection, cost attribution and a tested support route. Sample the actual behaviour rather than relying only on tags or configuration presence.

For example, a configured log destination should receive an identifiable test event that the authorised support team can find. A backup setting should connect to a recovery procedure appropriate to the workload.

Distinguish platform-provided controls from application responsibilities so a coverage report does not imply guarantees the foundation cannot establish.

## Use findings to improve the baseline

Compare onboarding results across workload types. A simple public site and a private data-processing service may expose different gaps.

Prioritise recurring manual work that can be removed without weakening the intended boundary. Update the reviewed baseline and test a fresh environment after the change.

The useful measure is whether teams can repeatedly deliver and support services within clear rules. A dashboard showing many provisioned accounts says little about that outcome unless those accounts support working, owned workloads.

## Sources

- [Microsoft: Azure landing zones](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/)