Share your experience using Harness

My main use case for Harness is continuous deployment (CD), specifically for safe, automated deployment to production, especially in Kubernetes and cloud environments.

For continuous deployment in my workflow, I use Harness by deploying a microservice to Kubernetes in production using a step-by-step workflow. Firstly, I code and build in GitLab, where the developer merges code to main, GitLab builds the app, runs tests, and creates a Docker image that is pushed to the container registry. GitLab triggers a Harness deployment with the new image tag. The second step is using the Canary strategy for deployment in Harness, where it deploys the new version to 10% of pods and partially shifts traffic to the new version. The next step is automated version monitoring, where Harness monitors key metrics such as error rates, latency, CPU, memory, and application logs. The fourth step involves decision and action; if metrics are healthy, Harness automatically promotes to 100%. If anomalies are detected, Harness automatically rolls back to the last stable version. The last step is approval and audit, where there is a manual approval step before full rollout for production and a full audit trail of who approved and when. As a result, production deployments are low risk and issues are caught within minutes, with no manual rollback needed and much higher confidence in releases.

The best features Harness offers, especially from a DevOps perspective, include intelligent continuous deployment, which is where Harness shines in deployment automation, not just running deployments, but doing them safely and reliably. Additionally, the automated verification with AI and ML is one of Harness's standout capabilities. Harness also has auto rollback features; if verification detects a failure pattern, Harness can automatically roll back to the last stable releases, eliminating manual rollbacks and speeding recovery. Other features include a unified deployment dashboard, feature flags and progressive delivery, which allow enabling or disabling features at runtime and targeting flags to specific user segments. Additionally, reusable pipelines and templates allow defining patterns once and reusing them across services or teams. All these features are awesome.

Harness has a strong positive impact on making production deployments safer, which really helps our organization. Production deployments are faster and more reliable, especially for Kubernetes and cloud-based services. This is the most important benefit that has helped our organization since we started using Harness. The impact includes significant reduction in deployment-related incidents, faster recovery when issues occur, and faster, more confident releases. Increased deployment frequency with higher confidence is another aspect, along with better governance and compliance, which made compliance easier and controlled access without slowing teams down. Harness also improved visibility across teams, resulting in better coordination between every team, whether it is Dev, QA, Ops, or SRE teams.

I can share some concrete metrics that show improvement, such as a 35 to 50% reduction in deployment-related production incidents. Meantime to recovery (MTTR) improved from 30 to 60 minutes before Harness to 5 to 10 minutes now. Automated detection and rollback led to 70 to 85% faster recovery. The deployment success rate increased from 80 to 85% to now 95% or more, showing fewer failed or partially failed releases.

The first point for improvement is the steep learning curve, where concepts such as services, environment, pipelines, and templates take time to understand. New users often need training before becoming productive, resulting in slower initial onboarding compared to simpler CD tools. An improvement idea is better guided onboarding with more opinionated defaults and examples. The second improvement can be on UI complexity and navigation; the UI can feel cluttered with many options and finding past executions, logs, or specific settings sometimes takes extra clicks, leading to small but noticeable productivity loss. Simplified UI views for common workflows and improved search and filtering could help. I also see cost and licensing as potential areas for improvement, as pricing can feel high for small teams and advanced features are tied to higher tiers, which may limit adoption for startups or smaller organizations. Flexible pricing models and more essential features in lower tiers could address this issue.

I have been using Harness for more than four years.

Harness is stable.

The scalability of Harness is really great; I would rate it a nine out of ten.

Harness customer support is really helpful anytime I try to reach out; they are available to assist with any issues I am facing. I have not encountered many issues, but on a couple of occasions, I reached out to them due to some problems on my side, and they quickly helped resolve my issues and provided suggestions.

Before adopting Harness, we used a CI-driven deployment approach with GitLab CI and Jenkins for both build and deployments, utilizing custom scripts for Kubernetes and VM deployments, along with basic health checks and manual rollbacks if something failed. While this worked reasonably well for CI, it had limitations for production deployments. The challenges we faced with this setup included high-risk, stressful deployments, manual monitoring during releases, manual and slow rollbacks, limited visibility into deployment health, and the requirement of senior engineers to be on call during releases. These were the reasons we switched to Harness, and since making that switch, we have seen a transformation in producing safer and more predictable deployments, significantly fewer incidents caused by bad releases, faster recovery, and less release fatigue for the team, eliminating the need for senior engineers to be on call during releases.

My experience with Harness pricing is that it uses a subscription-based modular pricing model. While it appears on the higher side compared to traditional CD tools, especially for smaller teams, for enterprises, the cost feels justified because of built-in deployment safety, automated verification, rollback, and strong governance and audit features. The initial setup cost is moderate to high, mainly due to the learning curve, pipeline and template design, and integration with CI, cloud, Kubernetes, and monitoring tools.

We did not evaluate other options. We directly looked into Harness and found that it offered all the specifications and features we were looking for, leading us to switch without exploring alternative applications.

This is a tricky question, but I can say that time is saved because we now save engineering time. Before, it required two to three engineers actively monitoring production during deployments, but after starting to use Harness, there is zero or minimal manual monitoring. Resulting in a 50 to 60% reduction in deployment-related human effort. The deployment success rate has also improved from 80 to 85% to more than 95%.

Talking about cost avoidance, we see indirect savings, as fewer incidents happen, leading to less escalation, outages, and less on-call fatigue. Consequently, the reduced dependency on senior engineers during releases has led to operational cost savings that offset licensing costs over time.

Day-to-day maintenance cost is low after setup, as no manual deployments are needed, and automated rollback reduces on-call effort. The return on investment (ROI) perspective shows that the reduction in incidents and faster recovery justifies the licensing cost for us, so I feel secure regarding the licensing part.

We did not evaluate other options. We directly looked into Harness and found that it offered all the specifications and features we were looking for, leading us to switch without exploring alternative applications.

I find myself relying on two very important features more often than the others: intelligent continuous deployment and auto rollback. These two are very impactful, as the auto rollback significantly reduces the blast radius of bad deployments and minimizes downtime. Cloud cost management is a bonus feature to add to the list, as Harness offers cost visibility for cloud resources, which helps our team optimize cloud spend tied to deployment pipelines.

If you run Kubernetes or a cloud-based production system, you should consider using Harness. It is great for frequent releases with real production risks, managing MTTR, rollback, and governance, all of which are important when working in IT. Harness keeps CI/CD responsibilities clear, avoiding overlapping responsibility and complexity. While it has a powerful offering, be aware of the steeper learning curve; hence, allocate time for training, documentation, and internal knowledge sharing. You will find good documentation for Harness to help you learn. The cost and budget are reasonable, and its scalability is great. Therefore, investing in it is worthwhile to deliver the most value for production-grade deployments. Start small, invest in observability, standardize pipelines, and measure MTTR and incident reduction to justify your costs. I would rate this solution a nine out of ten overall.

Harness has been implemented in our organization for one of our clients for approximately 8 to 10 months. Harness is particularly utilized for our infrastructure provisioning pipelines and our RITM ServiceNow requests.

With Harness CI/CD, one of our main use cases is using it as an infrastructure-provisioning pipeline. Harness allows us to have an end-to-end infrastructure pipeline, which connects our DevOps and our ServiceNow for governance and our custom portal, which we call an infrastructure-provisioning portal, and a central backend database through which we are able to provide a heterogeneous mixture of different resources including AWS, Databricks, Vault, IDMC, and GitHub repositories. Through this, we use Harness as the main platform where we are able to provision and manage all the pipeline executions as well as our requests that we receive for infrastructure provisioning.

Our team primarily interacts with Harness using their Pipeline Studio. That is one of our finest use cases, and currently, we are also looking forward to integrating Harness or working within Harness so that we can do more pipeline-as-code type development.

One of the best features Harness offers is the ability to templatize pipelines. Through template pipelines, we are able to reuse pipelines across different of our internal workstreams, and we are able to utilize various organization-level templates for various common use cases including ServiceNow RITM tickets or infrastructure-provisioning pipelines for Terraform.

Pipeline templatization has been a primary focus of my team, particularly because one of our infrastructure-provisioning requests always has a dependency on Terraform workspaces and GitHub creation. To address that, we resolved the issue by creating an end-to-end child pipeline that is part of our FTP platform. That pipeline is then utilized across all our different workstreams to provision Terraform workspaces and connect with Vault and GitHub IAC, so that we can effectively and reliably create infrastructure as code repositories. That is how we are able to work with templatization.

Harness Pipeline Studio is another feature that stands out. A good visual platform that allows us to see the pipeline end to end in an architectural manner is always helpful.

Harness UI can do a lot of good things. Harness's UI should not feel very complicated. At the current stage, it feels very commercialized and compared to other platforms such as Argo CD or Jenkins, which feel much more lively and much more simple. Infrastructure as code or pipeline as code is something that Harness severely lacks. There is not a lot of good support for pipeline as code, and I often find myself not using pipeline as code the way other platforms such as GitHub Actions or Jenkins integrate pipeline as code. Pipeline as code is definitely one of the disadvantages when it comes to Harness. Additionally, the entire platform feels very commercialized, which is something that a lot of developers, especially open-source enthusiasts, might not appreciate even within the organization.

One of the very important key factors I observed was that there is no way to execute nested pipelines, which means that we cannot execute child pipelines within child pipelines and child pipelines even within those child pipelines. There is no way to execute nested pipeline execution, which may or may not be required based on the use case, but it is definitely one of those features that I wish the platform had.

Harness has been implemented in our organization for one of our clients for approximately 8 to 10 months.

Harness is decently stable. I do feel there has been some downtime, but it may be a problem with our platform or our teams internally. Overall, I feel the platform is stable enough.

Harness scalability is good. It is able to work on our infrastructure side, which is EKS, and we are able to handle our organization growth effectively for an enterprise use case.

Although I have not directly interacted with customer support, we have been receiving incident reports whenever an incident occurs on Harness, and they are usually quick to respond, which is always an advantage.

Neutral

In my organization, we were and are still using GitHub Actions. GitHub Actions is the primarily CI/CD tool that we use, particularly because it comes with direct integration with our enterprise GitHub setup, and it is a natural tool that a lot of developers are familiar with in today's time. The reason why we shifted to Harness from GitHub Actions for a few of our edge use cases or newer use cases was because of pipeline templatization, a studio visual code development experience, as well as easy integration with other pipelines and templates that have been developed throughout the organization.

My organization opted for Harness through AWS Marketplace and by reaching out to professionals and support teams at Harness.

By adopting templates and various different pipelines across our own IDP platform, we have saved upwards of 30 to 40% of development time and also reduced risks of failures or error rates by upwards of 70%.

From what I understand with respect to Harness, licensing and setup costs were relatively low for an enterprise, and the pricing was more catered toward enterprises who would invest in the technology. The price that they pay extra for that technology compared to what they would have paid for open-source is then offset by the number of projects they are able to onboard.

In our organization, the only other option that we really evaluated was Argo CD. We did not go for Argo CD primarily because it was already open-source, and while using it, it felt more catered specifically toward Kubernetes, which was great. Our use cases are varied because we work with different domains such as AI and data engineering. We are dealing with a heterogeneous set of architecture, and while Argo CD did integrate nicely with Kubernetes-based deployments, it lacks severely in those other areas where Harness shines.

For others looking to use Harness, they should first evaluate their own organization to determine if Harness really solves all their use cases. Harness is somewhat use-case dependent, meaning while it definitely lacks in pipeline as code, it is still able to provide a pipeline-based studio, which is something that is unique to the platform itself. It could be a great performance booster for teams that are working heavily with other aspects of the application stack and not focused completely on pipelines. My overall rating of Harness is 6 out of 10.