New Feature: Billing Usage Analytics Dashboard
Our billing system is designed with simplicity and predictability in mind, incorporating the following elements to ensure you have complete control over your expenses:
- Users: At the rate of $0.96 per user per day ($29 per user/month), this element helps you track the cost associated with each team member's access to Qovery.
- Deployment Time: Priced at $0.016 per deployment minute, including 1000 minutes of free credits each month, allowing you to monitor and manage the cost efficiency of your deployment processes.
- Managed Clusters: Charged at $6.63 per managed cluster per day ($199 per managed cluster/month), this aspect offers insights into the costs tied to using Qovery's managed Kubernetes clusters.
- Self-managed Clusters: Providing $0 per month for up to 5 clusters, this allows you to leverage your own Kubernetes clusters without additional cost, promoting greater flexibility and cost savings.
Billing Analytics Dashboard
The billing analytics dashboard has been meticulously designed to offer you a clear and concise view of your spending across these four elements. Each section of the dashboard is dedicated to a specific cost component, displaying daily expenses and cumulative costs over your billing period. This granularity enables you to:
- Identify Trends: By observing your daily and monthly spending patterns, you can pinpoint areas where your usage aligns or deviates from your expectations.
- Optimize Resources: Understanding the specifics of your spending allows for strategic decision-making. For instance, if your deployment time costs are higher than anticipated, you might consider optimizing your CI/CD pipelines or leveraging your free deployment minutes more effectively.
- Maximize Value: With visibility into the costs of managed versus self-managed clusters, you can make informed decisions on the most cost-effective infrastructure setup for your projects.
Dashboard Access
To get access to your usage dashboard:
- Go to your Organization settings
- Click on "Billing & plans" > "Summary" tab
- Click on "Show usage" button
Then you can generate your report and set an expiration time (it can take up to 1 minute).
Once generated, you can copy the link and open it. ⚠️ Don't share it publicly.
And tada, your dashboard is accessible 🥳
Cost Optimization
This feature not only provides you insights into your current spending but also empowers you to take proactive steps towards optimizing your costs.
Whether through more efficient use of deployment minutes, adjusting team sizes based on project needs, or choosing the right cluster management option, the potential for savings is significant.
A Dashboard That Evolves With You
We understand that your needs and our platform are constantly evolving. As such, the billing analytics dashboard is subject to ongoing enhancements and improvements. Your feedback will be crucial in shaping its development, ensuring it remains as useful and user-friendly as possible.
Conclusion
Our new billing analytics feature represents a significant step forward in providing you with the transparency and control needed to manage your cloud expenses effectively. We are committed to supporting your journey towards more efficient and cost-effective cloud computing.
Stay tuned for further updates, tutorials, and guides on making the most of this feature. Your success is our priority, and we're here to support you every step of the way.
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)