Observability
Logs and metrics that help teams understand what the platform is doing
Get built-in application visibility with dashboards, real-time metrics, and live log access that fit the rest of the Wodby workflow.
Observability becomes more useful when it is close to the application platform instead of living in scattered tools with unclear ownership. Wodby gives teams a starting point for cluster, app instance, and service metrics together with live logs and task logs so they can troubleshoot faster with better context.
Start with built-in monitoring instead of assembling the basics first
Many teams need useful runtime visibility before they need a deeply customized observability stack.
Wodby collects metrics from cluster nodes, Kubernetes resources, app instances, services, pods, and containers when cluster monitoring is enabled. That gives teams a useful operational baseline before they need to build a custom observability stack.
Cluster-level metrics are available from the Kubernetes cluster view, while app instance and service metrics stay close to the workloads teams are operating.
Use real-time metrics to understand platform behavior
Metrics help teams connect resource usage, performance changes, and release outcomes.
Track CPU, memory, storage, restart, placement, and lifecycle signals to understand how workloads behave after a deployment or under load. Those signals are especially useful when paired with scaling and capacity planning decisions.
- Validate the impact of code and infrastructure changes more quickly.
- Spot capacity pressure before it becomes a customer-facing issue.
- Compare app instance, service, pod, and container behavior in one workflow.
- Use data instead of intuition when tuning resources, limits, and scaling rules.
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.
Connect third-party monitoring when the team needs deeper analysis
Some organizations want to centralize application monitoring across multiple platforms and services.
Built-in logs and metrics cover the operational baseline, while third-party monitoring integrations let teams attach specialized tools where they need deeper application analysis. For example, teams can connect New Relic through an integration and expose the required variables to the services that should report there.
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.