Container Apps are great for compute.
But the observability story is rough.
Here is what works, what does not, and what we did instead.
The Logs Exist, But Finding Them Is Hard
Container Apps send logs to Log Analytics.
That sounds good. Until you try to use it.
The logs are scattered across multiple tables:
- ContainerAppConsoleLogs for stdout/stderr
- ContainerAppSystemLogs for platform events
- AppEnvSpringCloudGatewayLogs if you use specific add-ons
We spent time writing Kusto queries just to see what our application logged.
Compare that to Application Insights, where logs are centralized and correlated automatically.
Container Apps can send logs to App Insights, but the integration is not automatic. You have to instrument your app yourself.
We ended up doing that. It should have been the default.
Distributed Tracing Requires Manual Work
If you want distributed tracing across Container Apps, you need to:
- add OpenTelemetry to your applications
- configure correlation IDs manually
- send traces to Application Insights or another collector
- ensure every app in the chain propagates context correctly
In Azure Functions or App Service, much of this works out of the box.
In Container Apps, it is your responsibility.
We use OpenTelemetry now. It works. But we had to build it ourselves.
For a platform that markets itself as simple, that is frustrating.
Metrics Are Basic
Container Apps expose basic metrics:
- CPU usage
- memory usage
- request count
- response time
That is useful for infrastructure monitoring. It is not enough for application observability.
You cannot see:
- custom business metrics
- dependency call duration
- error rates by endpoint
- queue depth or processing lag
You have to instrument those yourself and send them somewhere.
We use Application Insights custom metrics for this. It works, but it is extra code in every app.
Log Retention Is Short by Default
Log Analytics has a default retention of 30 days.
For production systems, that is not enough.
We extended retention to 90 days for critical tables. That increased our costs.
We also export logs to a Storage Account for long-term retention and compliance.
That setup is not specific to Container Apps, but it is not documented well in the Container Apps context.
We had to figure it out ourselves.
Startup and Crash Logs Disappear Quickly
When a Container App crashes on startup, the logs are often gone before you can see them.
The container restarts. The logs are not retained.
We missed critical startup errors multiple times because the logs vanished.
Our solution:
- configure longer log retention
- add verbose startup logging
- use init containers for pre-flight checks that log to persistent storage
This is not an elegant solution. It is a workaround.
What Actually Works
Despite the frustrations, some things work well:
- Log Analytics queries are powerful if you learn Kusto
- Integration with Application Insights gives you real observability
- Custom metrics and traces work if you instrument your code
- Dapr integration includes tracing out of the box
The tools exist. They are just not integrated or automatic.
What We Built Instead
We standardized our observability approach:
- all apps use OpenTelemetry for traces and metrics
- all logs go to Application Insights, not just Log Analytics
- we built reusable libraries for our common languages
- we enforce instrumentation in code reviews
It works. But it should not have required this much effort.
The Bigger Picture
Container Apps are still maturing.
The compute layer is solid. The networking works. The scaling is good.
But observability feels like an afterthought.
If you are coming from Functions or App Service, expect to do more work.
If you are coming from Kubernetes, this will feel familiar. You are already used to instrumenting everything.
We are staying on Container Apps. The compute benefits outweigh the observability gaps.
But we hope Microsoft invests more here.
Logging, tracing, and metrics should be first-class features, not things you build yourself.