Features¶
This page describes every section of the SLOpilot interface in detail. For initial setup, see Getting Started.
1. Dashboard¶
The Dashboard is the first page you see after logging in. It gives a high-level overview of your cluster's resource optimization status without requiring you to drill into individual workloads.
Summary cards — four cards at the top of the page show:
- Monitored Workloads: the number of namespaces and workloads currently being tracked
- Recommendations: the number of workloads that have received a recommendation out of the total monitored, with a progress bar
- CPU Rightsizing: aggregate current CPU requests versus recommended CPU requests across all analyzed workloads, with a net savings or increase figure
- Memory Rightsizing: the same aggregate view for memory
All four cards are clickable and navigate directly to the relevant page (Namespaces or Workloads).
Top CPU Requests and Top Memory Requests — two horizontal bar charts showing the five workloads with the highest CPU and memory requests respectively. Click a workload label to jump directly to its analysis view.
Top Optimization Opportunities — a ranked list of the five workloads with the greatest potential savings, expressed as a percentage. Each entry links directly to the workload's detailed analysis.
2. Namespaces¶
The Namespaces page lists all Kubernetes namespaces included in your license:
- Displays the count of Deployments and StatefulSets per namespace
- Sortable by namespace name or workload count
- Paginated for large clusters
- Click a namespace row to navigate directly to its workloads in the Workloads view
Note
Only namespaces permitted by your license are listed. If a namespace you expect to see is missing, check the namespace restrictions shown on the Settings page.
3. Workloads¶
The Workloads page is the main operational view. It presents a filterable, sortable table of every monitored Deployment and StatefulSet in your cluster.
Filters¶
- Namespace: filter to a single namespace or view all
- Type: filter by Deployment, StatefulSet, or show both
- Search: free-text search by workload name
Table columns¶
| Column | Description |
|---|---|
| Name | Workload name (monospace, links to analysis) |
| Namespace | Kubernetes namespace |
| Type | Deployment or StatefulSet |
| Replicas | Current replica count |
| CPU Request | Current CPU request per pod |
| Memory Request | Current memory request per pod |
| CPU Recommendation | Recommended CPU request with savings/increase indicator |
| Memory Recommendation | Recommended memory request with savings/increase indicator |
All columns are sortable. Click a column header to sort; click again to reverse the order.
Recommendation indicators¶
Each recommendation cell in the CPU and Memory columns uses a visual indicator to communicate the analysis result at a glance:
| Indicator | Meaning |
|---|---|
| Green arrow down with percentage | Savings opportunity — current request exceeds observed need |
| Red arrow up with percentage | Increase recommended — current request is below observed usage |
Grey neutral indicator (~) |
No significant change needed — current request is within tolerance |
| Amber Collecting... | Insufficient data — metrics are still being gathered for this workload |
Actions¶
- Click a row to open the detailed workload analysis view
- Select multiple rows using the checkboxes to generate a batch PDF report covering all selected workloads
- Kebab menu on each row provides a quick-refresh option to trigger a fresh analysis for that workload
4. Workload Analysis¶
The Analysis page provides a detailed breakdown for a single workload, with separate cards for CPU and Memory.
Reaching the Analysis page¶
Navigate here by clicking any workload row in the Workloads table, or by clicking a workload label in the Dashboard charts.
Recommendation cards¶
Each card (CPU and Memory) displays:
- Current request — the value currently configured in the workload spec
- Recommended request — the value SLOpilot suggests
- Delta — percentage change between current and recommended
- Confidence score — a measure of data completeness (see Understanding Recommendations)
- Reasoning — a plain-language explanation of why the recommendation was generated
- Historical usage chart — observed usage over the analysis window, with reference lines for the current request and the recommended value
Special states¶
Insufficient data — When the analysis engine has not yet accumulated enough metric history for a workload, the card displays an amber Collecting data badge. A dashed placeholder replaces the recommended value, and the reasoning block is replaced by an amber informational banner. The usage chart still shows any data that has been collected so far.
HPA detected — If a Horizontal Pod Autoscaler is managing the workload, an informational banner appears explaining that the analysis accounts for the autoscaler's scaling behaviour. Recommendations are still shown where sufficient data exists.
VPA detected — If a Vertical Pod Autoscaler is present, a banner indicates that the autoscaler manages resource allocation directly. SLOpilot displays an informational notice rather than competing recommendations.
Warnings¶
The Analysis page may display advisory warnings beneath the recommendation cards. These can include:
- High utilisation alerts (current usage close to or exceeding the request)
- OOM termination event detection
- Suggestions to increase a resource where the current request appears insufficient
5. Understanding Recommendations¶
SLOpilot uses a conservative analysis approach designed to optimise resource allocation while preserving application reliability. This section explains the principles behind every recommendation.
Key principles¶
Safety-first — All recommendations include safety margins above observed usage. This ensures that normal workload variability and short-lived spikes do not cause throttling or OOM terminations after a request reduction.
Independent analysis — CPU and memory are analysed separately. Each resource type has its own strategy tailored to how that resource behaves under contention.
Variability-aware — Workloads with irregular or spiky usage patterns receive proportionally larger safety buffers than steady-state workloads. A workload whose resource consumption is highly consistent receives a tighter recommendation than one whose usage fluctuates significantly.
OOM-aware — When out-of-memory termination events are present in a workload's history, the memory recommendation is adjusted upward accordingly, regardless of the raw usage figures.
CPU limits — SLOpilot does not recommend CPU limits. CPU is a compressible resource: under contention, Kubernetes throttles rather than terminates. Hard CPU caps can introduce unpredictable latency spikes that are often worse than throttling. Removing or omitting CPU limits is generally preferable for latency-sensitive workloads.
Memory limits — Memory limits are recommended with appropriate headroom above the memory request to accommodate temporary allocation peaks and avoid unnecessary OOM kills.
Confidence scoring¶
Each recommendation displays a confidence score that reflects how much historical data has been collected for that workload:
- Confidence increases gradually as more metric history accumulates
- Recommendations first appear after approximately one week of continuous monitoring
- Full confidence is reached after approximately two weeks, at which point the analysis engine has a complete picture of the workload's behaviour across the observation window
- A higher confidence score means the recommendation is derived from more data and is therefore more reliable
During the initial data collection period, workloads that have not yet reached the minimum data threshold display an amber Collecting... indicator rather than a recommendation. See Getting Started — Data Collection Warm-Up for more on timing.
Autoscaler awareness¶
HPA — When a Horizontal Pod Autoscaler is detected on a workload, the analysis engine adjusts its approach to account for the autoscaler's scaling behaviour and target utilisation settings. Recommendations still appear where sufficient data exists.
VPA — When a Vertical Pod Autoscaler is detected, SLOpilot displays an informational notice rather than a competing recommendation, since the VPA already manages per-pod resource allocation dynamically.
6. PDF Reports¶
SLOpilot can generate downloadable PDF reports for compliance documentation, team reviews, or stakeholder communication.
Generating reports¶
Single workload report — From the Analysis page, use the generate report action to produce a PDF for the workload currently being viewed.
Batch report — From the Workloads table, select multiple workloads using the row checkboxes, then use the batch report action to generate a single combined PDF covering all selected workloads.
Report contents¶
Each generated report includes:
- Workload metadata (name, namespace, type, replica count)
- Current and recommended resource values for CPU and memory
- Savings summary
- Historical usage charts
Managing reports¶
The Reports page lists all previously generated reports. From this page you can:
- Download any report as a PDF file
- Delete reports you no longer need
7. User Management¶
User management is available to Admin and Superuser accounts. Access it from the navigation.
Creating users¶
Admins can create new user accounts and assign one of three roles (User, Admin, or Superuser) at the time of creation. Users receive their initial credentials from the administrator out-of-band.
Password reset¶
Admins can generate a time-limited password reset token for any user. The token is displayed to the admin and must be shared with the target user through a secure channel (for example, a secure message or internal communication tool). The user then navigates to the reset password page, enters the token along with their chosen new password, and submits the form.
Profile¶
Every user can view their own account details and change their password from the Profile page (user icon in the navigation). The Profile page displays:
- Username
- Email address
- Role
- Member since date
- Last login timestamp
Changing a password immediately invalidates all other active sessions for that account.
8. Settings¶
The Settings page provides read-only system status and license information. Configuration changes are applied through Helm values, not through this UI.
System status¶
A health indicator shows whether the application server is currently operational.
Prometheus retention¶
The configured data retention period for the bundled Prometheus metrics store is displayed here.
License information¶
The license card shows:
| Field | Description |
|---|---|
| Status badge | Active (green), Unlicensed (amber), or Invalid (red) |
| Customer | The customer name associated with the license |
| Plan | The licensed plan name |
| Expires | Expiry date — green when valid, amber when expiring within 30 days, red when expired or expiring within 7 days |
| CPU Analysis | Whether CPU rightsizing is enabled by this license |
| Memory Analysis | Whether memory rightsizing is enabled by this license |
| Namespaces | Which namespaces are permitted, or Unlimited if unrestricted |
Note
Configuration changes — including Prometheus URL, license key, and all other settings — are managed via Helm values and cannot be modified from this page. See Configuration for details.
About¶
The About section shows the installed version of SLOpilot and a brief product description.