InfraWatts documentation
Understand the data, recommendations and limitations before deciding what to reduce, prepare or keep.
Product behaviour
InfraWatts brings infrastructure metrics together to detect waste and prioritise recommendations. The probe identifies the Linux or Windows host first, then detects Docker and Kubernetes independently. A Linux host remains a Linux host when these runtimes are present.
The dashboard, assistant, alerts, recommendations and exports read the same server state. Recommendations depend on observed metrics and context; inventory alone does not prove savings. The selected probe remains the default scope.
Assistant scope
The assistant uses the selected probe by default. A global question can expand the analysis to multiple probes; explicitly mentioning another probe can change the scope if it belongs to your account.
Use /infra, /alerts and /agent <name> to clarify a request. The visible context can include the probe, runtimes and Kubernetes state. An action recommendation is not evidence of execution.
Runtime detection
The host platform is identified before runtimes. Detection and availability are separate: Docker or Kubernetes can be detected while unavailable.
k8s_not_configured means no usable Kubernetes context; k8s_unreachable means a configured cluster is unreachable; docker_unavailable means the Docker daemon is unreachable. These warnings remain visible even without a critical alert.
Alerts and severity
critical alerts include offline probes, unreachable configured runtimes and severe risks. warning alerts cover degradation, CPU or memory pressure and configuration issues. info alerts provide low-risk advisory signals.
The alert centre brings incidents and runtime warnings together with the probe, cause and available details. No critical alert does not mean no warnings. Hiding an alert does not fix the infrastructure.
Efficiency score
The 0–100 score combines observed CPU utilisation and estimated or available power data to highlight underuse, efficient zones and overload. Very low CPU usage or disproportionate consumption can lower the score.
The score helps prioritise optimisation opportunities. It does not replace validation of peaks, memory, dependencies and workload capacity requirements.
Rightsizing recommendations
Recommendations combine CPU, RAM, hosting context and a provider catalogue when available. Generic recommendations remain possible for physical servers or uncertain providers.
A recommendation shows confidence, a target profile, limitations and available estimated impact. The displayed instance is a catalogue example. Validate dependencies, peaks, risk and rollback before changing infrastructure; estimated savings are not realised savings.
Reports and exports
JSON, CSV and PDF exports share a normalised dataset: hosts, cumulative energy, cumulative CO₂ and per-probe time series. They support decisions using the available data.
Select all probes or a subset and choose the report language. The PDF exposes assumptions and measurement limitations. Observation, decision and strategy windows are separate.
API and OpenAPI
Interactive documentation is available at /api/docs/ and the schema at /api/schema/. Authenticated access remains subject to account permissions.
The documented /api/v1/ scope includes GET /api/v1/agents (probes and alert summary), GET /api/v1/metrics (metrics), GET /api/v1/alerts (alerts), GET /api/v1/recommendations (recommendations) and GET /api/v1/audit (report dataset).