Azure App Service Linux: deployment completed but manifest unchanged; safe read-only diagnosis?

Treat the deployment record and the manifest as separate evidence: query deployment status first, then inspect /home/site/wwwroot through Kudu only if the stopped app’s SCM site remains available—without starting the app or changing access restrictions.

1. Record the app and SCM stopped state

In Azure Cloud Shell, run these read-only queries:

az webapp show \
  --resource-group <resource-group> \
  --name <app-name> \
  --query "{state:state, scmSiteAlsoStopped:scmSiteAlsoStopped}" \
  --output json

az webapp config show \
  --resource-group <resource-group> \
  --name <app-name> \
  --query "{linuxFxVersion:linuxFxVersion, alwaysOn:alwaysOn}" \
  --output json

Also check Azure portal → App Service → Properties → Site status. It reports the platform runtime state, including Stopped, Updating, or Unknown; it does not verify deployed file contents.^1^

The important result is scmSiteAlsoStopped:

• false or absent: stopping the app does not normally stop its SCM/Kudu companion site.
• true: stopping the app also stops SCM/Kudu, so SCM-hosted file and deployment-log inspection should not be expected to work while the app remains stopped.^2^

Do not change this property merely for diagnosis.

2. Query deployment status separately

Use the documented deployment commands:

az webapp log deployment list \
  --resource-group <resource-group> \
  --name <app-name> \
  --output json

az webapp log deployment show \
  --resource-group <resource-group> \
  --name <app-name> \
  --deployment-id <deployment-id> \
  --output json

Add --slot <slot-name> if the deployment targeted a slot. Without it, the production slot is queried. The first command lists deployments; the second returns the log for the selected deployment.^3^

For an explicit management-plane check, the documented operation is:

GET https://management.azure.com/subscriptions/[Subscription ID]/resourceGroups/[Resource Group] Group]/providers/Microsoft.Web/sites/{name}/deployments/{id}/log?api-version=2026-07-15

Its response contains deployment metadata such as active, status, start_time, end_time, message, and details.^4^ These fields describe the deployment operation; they do not attest that a particular manifest value is installed.

The nested Unauthorized/Forbidden response means this log request did not produce usable deployment evidence. It does not, by itself, establish either deployment failure or unchanged files.

3. Inspect installed content without starting the app

This is possible only if all three conditions hold:

1. scmSiteAlsoStopped is false.
2. The caller has Kudu authorization, including Microsoft.Web/sites/publish/Action.
3. The client is allowed by the SCM endpoint’s existing network restrictions.

Kudu is the App Service deployment/SCM companion site and exposes file and REST facilities. Website Contributor is an example of a least-privileged built-in role containing the required Kudu action.^5^

Open App Service → Development Tools → Advanced Tools → Go, then use the Kudu file view or debug console to read—not edit—the deployed manifest under:

/home/site/wwwroot/<manifest-path>

Also inspect existing deployment records under:

/home/LogFiles/Git/
/home/site/deployments/

App Service documents these as deployment-log locations, and deployment logging is automatic.^6^

SCM has its own access-restriction rule collection, or it can inherit the main-site rules. A disallowed request receives HTTP 403.^7^ Leave those rules unchanged as requested; a 403 from Kudu is an access-boundary result, not evidence about file contents.

If SCM inspection is unavailable

Browser SSH and az webapp exec are not alternatives while the app remains stopped: both require the app and its container to be running, as well as SCM authorization and network connectivity.^8^

Therefore, if SCM is stopped or inaccessible under the current restrictions, no documented live container inspection can verify the installed manifest while preserving all stated constraints. Preserve and compare:

• the manifest already read after deployment;
• pipeline logs and package hashes;
• the deployment ID and timestamps;
• existing App Service deployment logs available from storage or Kudu;
• the exact ARM error, correlation/request ID, and timestamp for a support request.

For ZIP deployment, expected content is /home/site/wwwroot; Kudu may skip copying individual files whose timestamps match existing files, so package contents, timestamps, and the post-deployment manifest should be compared.^9^

References

1. Use the App Service site status page
2. Site interface-Property Details
3. az webapp log deployment show
4. Web Apps - List Deployment Log - REST API (Azure App Service)
5. Kudu service overview - Azure App Service | Microsoft Learn
6. Enable diagnostic logs for apps in Azure App Service
7. Set up Azure App Service access restrictions
8. Open a container shell (SSH) and run commands in Azure App Service (container-linux)
9. Deploy files to Azure App Service