Observability
Logs, metrics, and debugging tools for running applications
Stream live logs, inspect service metrics, connect symptoms to deployments, and open a container web shell when direct investigation is needed.
- Stream application and service logs while an issue is happening
- Use service metrics to spot resource pressure and abnormal behavior
- Debug a running container through the web shell when necessary
Stream logs live when you need to investigate a problem
Fast access to logs is often the difference between a short investigation and a long outage.
Wodby lets teams watch application logs as events happen. That is useful during deployments, while verifying fixes, and when debugging issues that only appear under real traffic or in a specific environment.
Deployment, build, cron, and action logs are also available from their related tasks, so teams can connect runtime symptoms with the platform operations that may have caused them.
Give your agent evidence before asking it to fix a problem
Connect an MCP-capable agent to investigate a specific application and environment with read-only access.
Task logs explain what happened during a build, deployment, or platform operation. Application logs show what the running containers report. Your agent can inspect both, relate failures to repository code when you separately grant repository access, and propose a fix.
- Inspect the failed task and its steps before assuming the application is at fault.
- Read a bounded log sample or watch a selected service for a limited period. MCP log watches are not permanent background monitoring.
- Ask for evidence and a proposed fix before authorizing changes. Logs may contain sensitive data.
Investigate the latest failed staging deployment for this app. Review the task logs and relevant application logs, summarize the evidence, and propose a fix. Do not change configuration or deploy anything.
Connect your agent or follow the troubleshooting workflow.
Use service metrics to understand runtime behavior
Connect resource usage, restarts, and lifecycle changes to releases and traffic.
Track CPU, memory, storage, restart, placement, and lifecycle signals for app environments and services. Use those signals to validate a deployment, identify capacity pressure, and tune service resources from evidence instead of guesswork.
- Spot resource pressure before it becomes a customer-facing issue.
- Compare service and container behavior after a deployment.
- Use metrics when tuning resources and scaling rules.
- Connect third-party monitoring when deeper application analysis is required.
Open a container web shell for targeted debugging
Inspect runtime state directly without publishing a public SSH endpoint.
Open an interactive shell from a running app service, choose the workload and container, and run focused diagnostic commands. The web shell is a troubleshooting tool for exceptional cases; application changes should still move through the normal CI/CD and configuration workflow.
Learn more about web shell access and service settings on the Service configuration page.
Next step
Troubleshoot with better context before incidents turn into long investigations
Give teams a clearer operational baseline with metrics and log access that live alongside the rest of the application platform.