App Service Linux: Kudu /api/command remains pending after restart while health and VFS reads succeed

Question

App Service Linux: Kudu /api/command remains pending after restart while health and VFS reads succeed

Anas Omar Ibrahim 0

We are qualifying a closed prelaunch App Service Linux application. A small, authorized read-only Python command runs through the authenticated Kudu /api/command endpoint and writes a digest-bound result file outside the application's publication directory. Earlier captures completed successfully.

After an acknowledged application restart, public application health became healthy, and authenticated VFS reads remained available. The next command request stayed represented by a header-only pending Kudu trace, and its result directory did not appear during a bounded observation window. This is an unknown execution outcome; the command has not been resubmitted, and dependent deployment steps were stopped.

Existing application metrics do not show a clear CPU or memory pressure event. The built-in Container Issues detector reports startup success, while the Process List detector has no process data for the incident window. The process API returns HTTP400 for this Linux environment. No diagnostics settings, access controls or protections have been disabled.

Which existing read-only platform evidence can distinguish request admission/body handling, SCM command execution, and result delivery in this situation? Is there a documented way to determine the existing command outcome and verify SCM command readiness after a restart without replaying the uncertain command, restarting again, enabling new logging, changing permissions or purchasing a support plan?

We are seeking a cause-based diagnosis before any new bounded action. No application data or credentials are included here.

0 comments

1 answer

Your answer

Answer 1

The existing evidence can establish only partial stages of the request; if no correlated HTTP record, SCM execution record, or digest-bound result artifact already exists, the historical /api/command outcome remains indeterminate without Microsoft App Service backend telemetry.

1. Request admission and body handling

Use any already-collected client, gateway, reverse-proxy, or AppServiceHTTPLogs records for the incident UTC window.

A completed client upload plus an HTTP response proves more than the header-only trace.
A header-only pending trace proves that some HTTP response metadata reached the client; it does not prove that Kudu received the complete request body or dispatched the command.
AppServiceHTTPLogs is available for Linux App Service, but the documentation does not state that it necessarily includes SCM/Kudu traffic. Treat it as evidence only after confirming that existing rows contain the SCM hostname or /api/command path ^1^.

If an existing Log Analytics workspace contains those records, start with a broad search rather than assuming a particular URI column:

search in (AppServiceHTTPLogs) "api/command"
| where TimeGenerated between (
    datetime(2026-01-01T12:00:00Z) ..
    datetime(2026-01-01T12:10:00Z)
)
| order by TimeGenerated asc

Replace the timestamps with the bounded incident window. Then correlate any available SCM hostname, client IP, status, instance identifier, and request ID with the original trace. An HTTP row ordinarily establishes request-level routing metadata—not complete body receipt or command dispatch.

2. SCM execution evidence

Download the existing diagnostic dump without changing logging:

App Service → Development Tools → Advanced Tools → Go
In Kudu, select Tools → Diagnostic dump.
Search the extracted /home/LogFiles content for the incident timestamp, request/correlation ID, command filename, digest, result path, or distinctive arguments.

For Linux, the dump contains available Docker host and container console logs; scaled-out apps include a set for each instance. Deployment logs are under /site/deployments/ ^2^.

This proves execution only if an already-existing correlated entry records command start, exit, failure, or output. The general availability of a diagnostic dump does not mean /api/command executions were logged. Deployment history is relevant only if the command was part of deployment processing; Kudu automatically records deployment logs, not arbitrary command history ^2^.

The empty Process List detector window and Linux process API HTTP 400 supply no positive evidence about whether this command ran. If this is a custom container, the SCM site is in a separate container and cannot inspect the app container’s processes or filesystem, so SCM process/file views are not an app-container execution oracle ^3^.

3. Result delivery

The digest-bound artifact is the strongest application-level completion evidence:

Existing artifact with the expected digest and atomic completion marker: evidence of successful completion.
Existing temporary, partial, or error artifact: evidence that execution reached the write phase.
No directory or artifact: consistent with non-admission, failure before writing, execution on a different/nonpersistent filesystem, or interrupted execution. It does not distinguish those cases.

For custom containers, data outside /home or a mounted Azure Storage path resides in the container’s writable layer and is not durable platform storage ^3^.

4. Restart state versus SCM readiness

Public app health does not establish SCM command readiness. Health Check evaluates a customer-configured application endpoint, while Site status reports platform runtime state ^4^.

For existing evidence:

App Service → Properties → Site status: record state, last error, occurrence time, and affected instance.
Diagnose and solve problems → Web App Restarted: correlate restart/reallocation events.
Review existing AppServicePlatformLogs for container operations and AppServiceAuditLogs for Kudu login activity. Audit login activity does not prove command execution ^1^.

No documented public App Service/KuduLite mechanism in these references exposes a durable /api/command operation record that can now be queried for completion, nor a read-only readiness contract specifically for that endpoint. WEBSITE_START_SCM_WITH_PRELOAD can preload Kudu on Linux when Always On is enabled, but changing it would be prospective configuration—not historical evidence ^5^.

A current Kudu shell probe would also be a new observation, not proof of the earlier outcome. If later authorized, az webapp exec --target kudu can test current SCM shell availability; it cannot reconstruct the previous request ^6^.

If no correlated artifact exists

Only Microsoft Azure App Service support can inspect internal platform telemetry needed for definitive historical attribution. Open Azure portal → Help + support → Create a support request, select the App Service resource and a technical issue, and provide UTC timestamps, SCM hostname, instance identifiers, response headers/request IDs, restart time, and the untouched client trace. Microsoft Q&A and self-service detectors cannot inspect backend request telemetry.

A definitive technical investigation may require an eligible support plan. Site Status, Resource Health, Service Health, and App Service Diagnostics remain available as self-service evidence, but cannot guarantee reconstruction of the command outcome ^4^.

References