Hello Team,

Check out this week’s changelog for exciting updates and enhancements from our team! 🚀

Announcing Qovery Observability

We are thrilled to announce the next major milestone in our platform vision: Qovery observability!

This new product launch is strictly tied to Qovery’s vision to empower developers with autonomy and confidence. It brings observability directly into their hands and helps shift infrastructure ownership left, closer to those who build and ship the software.

This is our developer-first observability product that brings everything you need into a single, unified view, completely integrated into our platform.

Qovery Observability - application visibility right within the Qovery console

Thanks to the work we’ve been doing over the past years on our infrastructure management and CI/CD product, you can trace an issue from a failing pod to a recent configuration change, a network spike, or a service deployment, and even get alerted before customers notice anything without switching tabs or chasing down disconnected dashboards.

It is fully integrated into our platform and it provides metrics, events and logs across your entire stacks in a clean, powerful interface that lets you move from high-level views to granular details in seconds.

And the best part? It’s fully managed. No maintenance, no glue code, no integration headaches. Just one click and you get the data all in one place.

Have a look at our official announcement here

Improved deployment history: keep the last deployment

We’ve updated the retention rules for the Deployment History section. From now on, we will ensure that at least the last deployment of each service within an environment is always retained.

Previously, only the last 20 deployments were kept, regardless of the service. This led to confusion, especially for services that are deployed infrequently, as their last deployment record could be lost.

With this improvement, you can now be confident that the deployment history includes at least the latest deployment for every service, no matter how often it is updated.

Custom domain configuration is allowed only with a public port

We’ve improved the flow for configuring a custom domain on your application.

Now, a custom domain can only be configured if a public port is defined in the application settings.

This change ensures consistency and prevents misconfiguration, since a custom domain has no effect if the application is not exposed through a public port.

Public port mandatory for custom domain

Service running status loading improvement

We’ve heard your feedback, and we’ve fixed it: no more misleading service statuses.

In some cases, services were incorrectly displayed as “stopped” when they were actually running, forcing you to manually refresh the page to see the real status.

We’ve reviewed and improved our WebSocket system to ensure real-time and reliable status updates, so you always have an accurate view of your services.

Minor Changes:

• Improved error messages: we have reviewed a few error message texts, including the "No ingress found" error.

For the latest news and upcoming features, remember to check out changelog.qovery.com.

As always, we appreciate your feedback and support.

Happy Deploying!

The Qovery Team 🚀