This page offers details and License Unit descriptions for each product module to help customers make informed procurement and deployment decisions. Harness may modify these product descriptions to reflect new features or changing practices, but the modifications may not be retroactive or materially decrease Harness’s overall obligations during an Order Form Term.
Many of the Modules are licensed under the “Developer” License Unit, described here:
“Developer” means each person, identified by a specific, unique email address, who is an employee, agent, or contractor of the Customer or Customer’s Affiliate that accesses Software or the Harness Platform directly, or contributes to code development, deployment, security, maintenance, optimization or any other technical activities related to software code that is managed with Harness products, across all production and non-production environments. For clarity, even if a person undertakes more than one of the activities described above, each such person shall only be counted as one Developer. If a customer wishes to use bots or robotic process automation to run the Software or Harness Platform, Customer must first obtain Harness’s prior written consent and such usage may be subject to additional restrictions. Harness may revise the definition of a Developer upon notice to the Customer, however the modifications may not be retroactive or materially decrease Harness’s overall obligations during an Order Form license term.
For Modules with License Units that include “Developer” and other supplemental License Units, the “License Unit Description” column lists “Developer +” along with the additional information.
The list of subprocessors for each Module can be found here: Subprocessors . Customers must subscribe to this page to receive notifications of changes to the list of subprocessors. To subscribe, visit Harness Trust Center(https://trust.harness.io), scroll down to the “Trust Center Updates” section, and click “Subscribe to updates.”
The Statements of Work for the following Professional Services offerings are available at the applicable URL:
| Product Name | Product Description | License Unit Description |
|---|---|---|
| Continuous Integration (CI) | https://developer.harness.io/docs/continuous-integration | Developer+
For more details regarding how Harness Cloud Credits are calculated and utilized, please visit our Continuous Integration Subscriptions and license FAQ below, the terms of which are incorporated into this Order Form. https://developer.harness.io/docs/continuous-integration/ci-quickstarts/ci-subscription-mgmt/#harness-cloud-billing-and-build-credits |
| Continuous Delivery (CD) | https://developer.harness.io/docs/continuous-delivery | Developer +
Each Developer may use up to .33 CD Services. If there are more than 20 Service Instances in any of these CD Services, such additional CD Service Instances will count towards another Harness CD Service. A "CD Service" is an independent unit of software that is managed, tracked, and deployed using Harness Continuous Delivery (CD) and Harness GitOps. A CD Service may include, but is not limited to, the following: A binary running a daemon or application. A script or executable. A containerized service (e.g., Docker container). A virtual machine (VM). A serverless function (e.g., AWS Lambda, Google Cloud Function). An application synced via GitOps to a unique infrastructure. Custom definitions as configured within Harness Continuous Delivery. A “Service Instance” refers to the pods or instances of a CD Service deployed to a host. CD constantly tracks the instances of a Service deployed at a sixty (60) minute cadence. Harness tracks all SIs for all deployed Services at a sixty (60) minute cadence, when reporting for license consumption. Additionally, Harness takes the 95th percentile of all SI data points seen over the last 30 days for the Service, and uses this value as the number of SIs for the Service. |
| Feature Flags (FF) | https://developer.harness.io/docs/feature-flags | Developer +
"Monthly Tracked Keys" ("traffic keys") correspond to the number of unique user, device, account or other keys upon which feature flag decisions are based. Harness FF tracks your MTKs within a calendar month. |
| Feature Management & Experimentation (FME) | https://developer.harness.io/docs/feature-management-experimentation |
Developer +
"Monthly Tracked Keys" ("traffic keys") correspond to the number of unique user, device, account or other keys upon which feature flag decisions are based. Harness FF tracks your MTKs within a calendar month. An "Event" is a record of user or system behavior. Events can be as simple as a page visited by a user, or a user interacting or seeing a feature controlled or managed by FME. As part of Customer’s subscription to the Harness Feature Management and Experimentation product (FME), Harness will include: (i) Harness’ internal CDN usage to serve customers and (ii) Customer’s transmission of impressions to Harness’ infrastructure. Harness provides a daily quota of 5,000 daily CDN requests per Monthly Tracked Key (MTK) entitlement and 5,000 daily received impressions per MTK entitlement. If Customer exceeds this limit, Customer may receive a notification from Harness and will be subject to overages at the cost of $0.20 per million CDN requests and $0.15 per million impressions if the issue is not resolved within 5 business days of receiving the notification for overages. A “Warehouse Native Experiment” is an experiment driven directly by a connected data warehouse to assign variations and calculate metrics. For billing, each experiment is counted only once upon its initial calculation. All subsequent recalculations for that experiment are included at no extra cost. |
| Cloud and AI Cost Management (CACM) | https://developer.harness.io/docs/cloud-cost-management | Fees are charged as a percentage of the Total Tracked Cloud Spend, as tracked by Harness, up to a certain agreed upon amount, as stated in the Order Form.
“Total Tracked Cloud Spend” means the annual cloud costs data transmitted to and measured by CACM via the Harness API integration. The fees for Harness Cloud and AI Cost Management - Cloud Cost Insights are charged at 1% of Customer’s Harness total tracked cloud spend up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. The fees for Harness Cloud and AI Cost Management - Commitment Orchestrator are charged at 1.25% of Customer’s Harness total tracked EC2 cloud spend up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. The fees for Harness Cloud and AI Cost Management - Autostoping are charged at 1.25% of Customer’s Harness total tracked cloud spend in nonproduction environments up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. The fees for Harness Cloud and AI Cost Management - Cluster Orchestrator are charged at 2% of Customer’s Harness total tracked cloud spend in Kubernetes environments up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. |
| Security Testing & Orchestration (STO) | https://developer.harness.io/docs/security-testing-orchestration | Developer +
Each Developer is entitled to one hundred (100) Security Scans per month. A “Security Scan” is a single execution of a security test initiated through STO against a unique application target, service, or codebase. Security Scans can be triggered via automation, scheduled jobs, or manual execution. Additionally, the Security Scan may cover multiple files or endpoints, depending on the configuration, but is counted as one Security Scan per test execution. |
| Service Reliability Management (SRM) | https://developer.harness.io/docs/service-reliability-management | Developer +
Each Developer may use up to .33 SRM Services. An "SRM Service" is an independent unit of software that is managed and tracked using SRM. A SRM Service may include an application, metric, datapoint or other measurement that is managed by monitoring systems or tools like Prometheus or other application performance monitoring (APM) vendors. |
| Resilience Testing (RT) | https://developer.harness.io/docs/resilience-testing/ |
Developer + Each Developer may use up to 0.33 RT Services. A “RT Service” is any Target Resource that undergoes chaos experiments during a 12-month period using RT. A Target Resource may include but is not limited to
Running a chaos experiment using RT on each of these Target Resources above counts as one RT Service. For any other Target Resources not listed above, 100 chaos experiments on the non-listed Target Resource is equal to one RT Service. Repeated experiments on the same Target Resource within the 12 month period do not count as additional RT Services. |
| AI DLC Insights (AIDI) | https://developer.harness.io/docs/software-engineering-insights | Developer |
| Infrastructure as Code Management (IaCM) | https://developer.harness.io/docs/infrastructure-as-code-management | Developer+
Each Developer is entitled to ten (10) Executions per month. An Execution is defined as a successful run of a Terraform apply or Terraform destroy command that results in resource changes (i.e., provisioning, updating, or decommissioning infrastructure). An Execution includes, but is not limited to:
(a) Terraform / OpenTofu. One billable Workspace equals one state file. Each Terraform or OpenTofu Workspace configuration manages a single, independent state file and constitutes one (1) billable Workspace. (b) Terragrunt. One billable Workspace equals one Terragrunt unit. A Terragrunt unit is defined as a single directory containing a terragrunt.hcl file that manages an independent state file. Each such unit constitutes one (1) billable Workspace, regardless of whether multiple units are managed under a single Workspace configuration in the Harness platform. As an example, if a Workspace configuration encompasses 4 Terragrunt units (each with its own independent state file), then the billable count is 4 Workspaces. "Active Host" means a unique host against which at least one Ansible playbook has been executed through Harness IaCM within the preceding thirty (30) day period. Each such unique host constitutes one (1) billable Active Host. A host that has not been the target of any playbook execution within the preceding thirty (30) days is deemed inactive and does not constitute a billable Active Host. Harness continuously tracks the count of Active Hosts throughout the billing period. For the purpose of reporting license consumption, Harness applies a high-watermark methodology and uses the maximum Active Host count observed at any point during the current billing period as the billable Active Host count for that period. |
| Supply Chain Security (SCS) | https://developer.harness.io/docs/software-supply-chain-assurance | Developer+
Each Developer is entitled to one hundred (100) supply chain Executions per month. An Execution is defined as a single end-to-end run of a security validation workflow initiated by SCS. This includes the scanning, analysis, or attestation of a software artifact, dependency set, build process, or pipeline stage for integrity, provenance, and risk signals. One Execution includes a complete scan or verification of an artifact (e.g., container image, software package, binary, or manifest) initiated by a user, pipeline, or automated policy. Executions may involve multiple steps such as SBOM (Software Bill of Materials) generation, signature validation, dependency scanning, and compliance checks—but are counted as one execution per artifact per scan event. Applies to both pre- and post-deployment validation workflows. |
| Internal Developer Portal (IDP) | https://developer.harness.io/docs/internal-developer-portal | Developer |
| Database DevOps (DB) | https://developer.harness.io/docs/database-devops | "DB Instance" means each copy of a Schema deployed within a database environment.
A "Schema" is the structure or system that defines the organization of data, including tables, relationships, views, and other database objects. It provides a blueprint for how data is stored, accessed, and secured within the database. |
| Artifact Registry (AR) | https://developer.harness.io/docs/artifact-registry/ | "GB Storage" refers to the amount of digital storage, measured in gigabytes (GB), that is allocated for storing and managing artifacts within the Artifact Registry. Artifacts may include software packages, binaries, libraries, and other build-related components that are created, versioned, and stored for use in development and deployment processes. |
| DevOps Essentials | The DevOps Essentials bundle includes:
|
Developer+
The license unit descriptions of each of the included product modules will also apply, along with the following descriptions: STO A “Security Scan” executes the Security Testing Orchestration (STO) step within a pipeline. This involves scanning a target for security vulnerabilities. A “target” can be a repository, container image, configuration, or live application. CD A "Deployment Event" occurs when a CD Service is distributed, deployed, upgraded, or otherwise delivered to an Environment using any deployment strategy, including but not limited to manual, automated, blue-green, canary, or rolling deployments. Deployment Events are considered billable i) when a new CD Service is successfully deployed to an Environment, or ii) when an existing CD Service in an Environment is updated, upgraded, or modified. An "Environment" means a designated infrastructure or set of infrastructures where a Service is deployed, such as development, staging, or production environments. Exclusions: Deployment Events do not include processes or activities outside Harness CD and Harness GitOps unless specified in the applicable agreement. CI A "Cloud Credit" represents one minute of compute time consumed on Harness cloud infrastructure to execute pipeline stages or processes initiated by the customer. Cloud Credits are applicable when utilizing Harness modules that rely on Harness cloud resources for execution, including but not limited to Continuous Integration (CI), Security Testing Orchestration (STO), and Infrastructure as Code Management (IaCM). Cloud Credits are influenced by the following factors: - Operating System: The type of operating system used for the execution, which may affect resource consumption. - Allocated Resources: The virtual computing resources provided for execution, such as CPU, memory, and disk usage. Each pipeline stage or process executed on Harness cloud infrastructure, regardless of its complexity or duration, contributes to the consumption of Cloud Credits. Exclusions Cloud compute minutes do not include execution time or resources consumed on customer-owned infrastructure or external systems integrated with Harness unless explicitly specified in the customer agreement. IACM A "Deployment Event" occurs when executing an Infrastructure as Code Management (IaCM) stage within a pipeline that involves a Workspace through Terraform or OpenTofu commands. Each i) execution of an IaCM stage in a pipeline, or ii) action performed to create, update, destroy infrastructure resources defined in the state file associated with the Workspace, constitutes a billable Deployment Event. "Workspace" means a single, independent unit of infrastructure managed through Harness Infrastructure as Code Management (IaCM). A Workspace represents the smallest independently provisionable, modifiable, and trackable collection of infrastructure resources within a given IaC framework. The billable Workspace count is determined as follows: (a) Terraform / OpenTofu. One billable Workspace equals one state file. Each Terraform or OpenTofu Workspace configuration manages a single, independent state file and constitutes one (1) billable Workspace. (b) Terragrunt. One billable Workspace equals one Terragrunt unit. A Terragrunt unit is defined as a single directory containing a terragrunt.hcl file that manages an independent state file. Each such unit constitutes one (1) billable Workspace, regardless of whether multiple units are managed under a single Workspace configuration in the Harness platform. As an example, if a Workspace configuration encompasses 4 Terragrunt units (each with its own independent state file), then the billable count is 4 Workspaces. "Active Host" means a unique host (“Unique Host”) against which at least one Ansible playbook has been executed (each, an “Instruction”) through Harness IaCM within the preceding thirty (30) day period. Together, each such Unique host and at least one Instruction constitutes one (1) billable “Active Host”. A Unique Host without at least one (1) Instruction within the preceding thirty (30) days is deemed inactive and does not constitute a billable Active Host. Exclusions. Actions or commands performed outside the IaCM stage in the Harness platform, and operations that do not involve referencing a Workspace or managing resources defined within a state file, are not considered Deployment Events. If Customer’s use of the Harness Platform exceeds the number of License Units set forth in the Order Form, Customer will be billed for such excess use at the end of the month in which such excess use occurs. |
| API Discovery | https://docs.traceable.ai/docs/api-catalog | “API Endpoint” refers to a specific URL or location on a server where an API can access the resources or services it needs to perform its functions. |
| API Security Testing | https://docs.traceable.ai/docs/api-testing | “API Endpoint” refers to a specific URL or location on a server where an API can access the resources or services it needs to perform its functions. |
| API Protection | https://docs.traceable.ai/docs/traceable-runtime-protection |
“API Call” means any discrete unit of communication initiated by a software component (including but not limited to a web browser, mobile application, API consumer, backend service, or automated script)—to a service, endpoint, or resource that is processed and/or protected by the Platform. API Calls may occur over various supported protocols, including but not limited to HTTP, gRPC, or WebSocket, and originate from interactive user actions, background processes, system integrations, or automated workflows.
Each API Call is counted individually, regardless of its source or intended function, whether the request is allowed, blocked or flagged by API Runtime Protection, and contributes to the Customer’s usage volume for billing and quota purposes. To ensure a consistent and predictable service experience, the Customer’s monthly API Call entitlement is provisioned as a continuous rate over time and expressed as an equivalent Calls Per Minute (CPM) capacity, which governs request processing on the Platform. During periods of elevated request volume, the Platform may manage traffic in real time to maintain overall service quality, and does not guarantee unlimited burst capacity beyond the calculated CPM, including in cases where the total monthly entitlement has not yet been fully utilized. |
| Web Application Firewall | https://docs.traceable.ai/docs/wap-api-protection |
“API Call” means any discrete unit of communication initiated by a software component (including but not limited to a web browser, mobile application, API consumer, backend service, or automated script)—to a service, endpoint, or resource that is processed and/or protected by the Platform. API Calls may occur over various supported protocols, including but not limited to HTTP, gRPC, or WebSocket, and originate from interactive user actions, background processes, system integrations, or automated workflows.
Each API Call is counted individually, regardless of its source or intended function, whether the request is allowed blocked or flagged by API Runtime Protection, and contributes to the Customer’s usage volume for billing and quota purposes. To ensure a consistent and predictable service experience, the Customer’s monthly API Call entitlement is provisioned as a continuous rate over time and expressed as an equivalent Calls Per Minute (CPM) capacity, which governs request processing on the Platform. During periods of elevated request volume, the Platform may manage traffic in real time to maintain overall service quality, and does not guarantee unlimited burst capacity beyond the calculated CPM, including in cases where the total monthly entitlement has not yet been fully utilized. |
| Bot & Abuse Protection | https://docs.traceable.ai/docs/bot |
“API Call” means any discrete unit of communication initiated by a software component (including but not limited to a web browser, mobile application, API consumer, backend service, or automated script)—to a service, endpoint, or resource that is processed and/or protected by the Platform. API Calls may occur over various supported protocols, including but not limited to HTTP, gRPC, or WebSocket, and originate from interactive user actions, background processes, system integrations, or automated workflows.
Each API Call is counted individually, regardless of its source or intended function, whether the request is allowed blocked or flagged by API Runtime Protection, and contributes to the Customer’s usage volume for billing and quota purposes. To ensure a consistent and predictable service experience, the Customer’s monthly API Call entitlement is provisioned as a continuous rate over time and expressed as an equivalent Calls Per Minute (CPM) capacity, which governs request processing on the Platform. During periods of elevated request volume, the Platform may manage traffic in real time to maintain overall service quality, and does not guarantee unlimited burst capacity beyond the calculated CPM, including in cases where the total monthly entitlement has not yet been fully utilized. |
| AI Test Automation | https://developer.harness.io/docs/ai-test-automation | Developer+
A “Test Run” is the execution of a single test on an application (i.e. web, mobile, backend, desktop, APIs etc.), an environment (i.e. development, QA/staging, production, pre-production), configurations, code changes or builds, using Harness AI Test Automation. Regardless of whether the Test Run is triggered via other Harness products, manually, or is pre-scheduled, each executed test, whether successful or failed, will count as one Test Run. If multiple concurrent tests or the same tests are executed across multiple environments (e.g. dev, QA, staging, prod), each executed test counts as a separate, individual Test Run. If a test is retried (e.g., after a failure or for any other reason), the retried test counts as one additional Test Run |
| AI SRE | https://developer.harness.io/docs/ai-sre | Developer |
| Static Application Security Testing - Enterprise (SAST) | Qwiet | “Developer” means a developer (unique person or entity) who has, within the last ninety (90) days, created or modified content, code, configurations, or artifacts using our Services or analyzed by our Services (counted once, even if to multiple repositories). |
| Software Composition Analysis (SCA) | Qwiet | “Developer” means a developer (unique person or entity) who has, within the last ninety (90) days, created or modified content, code, configurations, or artifacts using our Services or analyzed by our Services (counted once, even if to multiple repositories). |
| Code Repository | Harness Developer Hub |
Code Repository" means any use of the Harness provided git repositories and large file store within the Continuous Integration (CI) module.
“Bandwidth” means the sum total of data transferred to or from git repositories or large file store in Code Repository. “Storage” means the sum total of data stored on disk in git repositories or large file storage in Code Repository.Customer must ensure that the amount of data in Storage or transferred in Bandwidth does not exceed the limitations set in the Harness Code Repository module usage limits. Customer may petition Harness for an increase in these limits on a paid plan. Usage limits on free plans will not be extended. If Harness determines that Customer’s actual Storage or Bandwidth exceeds the usage limits, Harness may suspend Customer’s account, throttle Customer’s file hosting, or otherwise limit Customer’s activity within the Harness Platform until Customer enters a paid plan. In connection with the use of a free tier of Code Repository, Harness further reserves the right—after providing advance notice—to delete repositories that Harness determines will place undue strain or burden on its infrastructure or the Harness Platform. |
|
AI Discovery |
|
“AI Call” means any discrete unit of communication, inference request, or tool execution initiated by a software component (including but not limited to a web browser, mobile application, endpoint consumer, backend service, automated script, or AI entity such as an Agent or LLM) to a service, endpoint, model, MCP tool, or resource that is processed, monitored, and/or protected by the Platform. AI Calls may occur over supported protocols and interface standards, including but not limited to HTTP, gRPC, WebSocket, Server-Sent Events (SSE), or the Model Context Protocol (MCP), and may originate from interactive user actions, background processes, system integrations, agentic workflows, or automated processes. Each AI Call is counted individually, regardless of its source, purpose, or underlying transport mechanism, whether the request is allowed, blocked, or flagged by AI Protection policies, and contributes to the Customer’s usage volume for billing and quota purposes. |
|
Harness Codecov |
“User” means each individual who authors a pull request or merge request on a private service repository utilizing Codecov coverage, or accesses advanced features by logging into their Codecov instance. |
On this page