Stack Harbor PaaS ships with monitoring built into the dashboard. You do not need to deploy Prometheus, install agents, or stitch together log aggregators to get a usable view of an environment’s health. The platform collects metrics from every container, surfaces them in graphs, and lets you set thresholds that fire email notifications.
This section covers the three pieces that ship as standard:
- Statistics — RAM, CPU, disk, network, and IOPS per node, with configurable interval and duration.
- Log files — direct access to standard log files for every container type, with tail-style refresh.
- Load alerts — threshold-based notifications when resource usage crosses a percentage you define, sustained for a configurable time window.
Together, these cover the day-to-day questions: is the application healthy, is it hitting limits, what does the log say when something is wrong.
What this is not
Built-in monitoring is operational telemetry — what is going on right now and what happened recently. It is not a replacement for application-level observability (distributed tracing, structured metrics, custom dashboards). For that, run your own observability stack as one of the environment’s layers and ship metrics to it from your application.
Built-in monitoring is also bounded by what the container exposes through the platform’s collection agent. RAM, CPU, disk, network, and IOPS are first-class. Anything inside the application — request latency, queue depth, business metrics — is not.
Where to go from here
- Statistics monitoring — the metrics view in detail, including what each line on the graph means.
- Monitoring consumed resources — using the same data to track current usage against limits.
- Log files — the log viewer and what log files each container type exposes.
- Load alerts — defining alert thresholds and what the notification looks like.
For workloads that need more than the built-in surface, the platform’s Managed Cloud Ops engagement covers shipping logs and metrics into your own observability stack.