License metrics

Introduction

In this section, the billable license metrics for each component of Cumulocity are defined. These metrics are used for billing purposes and represent how Cumulocity computes each unit during the billing period. License metrics are used to quantify resource consumption, system usage, and service utilization for accurate and transparent billing calculations. Customers should refer to these definitions to understand how their usage of Cumulocity services is measured and billed.

Each version of the license metrics will be written with an effective date range. License metrics will not be updated during the duration of an active contract, and the version that is used upon signature will persist even if there are additional versions released afterwards. The start date for a contract will be used as the effective date for license metrics, and the version which is active at the time of the contract start date will be used for the duration of the contract.

The license metrics contained within this section are valid for “Commit-to-Consume” contracts and are not applicable to other contract types. To identify if your contract is a “Commit-to-Consume” contract, please follow up with your Cumulocity contract or view the contract directly.

Info
For the purposes of all license metrics, one “gibibyte” is defined as 1,073,741,824 bytes as is abbreviated ‘GiB’. A gibibyte may be colloqually referred to as a gigabyte and these names should be treated as the same value.

Version 1

This agreement is made between Cumulocity (“Provider”) and the customer (“Customer”) who utilizes the Provider’s hosted software solutions and services. The following license metrics define the usage measurements and calculations that form the basis for billing and invoicing of Cumulocity services.

These license metrics are valid for April 1st, 2025 onwards.

Deployment

A unique instance of the hosted software (“Software”) provided by the supplier (“Supplier”) and made accessible to the Customer. Deployments can be “Dedicated Cloud” instances or “Public Cloud” instances.

  • Dedicated Cloud deployments have dedicated resources provided for a single Customer.
  • Public Cloud deployments have shared resources provided for Customers. A Public Cloud deployment will not have data shared between Customers.

Cumulocity Dedicated Cloud deployments can be used for development or testing (“Non-Production”) purposes but are restricted in the scope of their usage. In this case, the Dedicated Cloud deployment may not be used for the processing of live production data or any purposes other than development or testing purposes only. A Non-Production Dedicated Cloud deployment may be subject to separate fees as written in the contract between Cumulocity and the Customer. Note that Cumulocity Public Cloud deployments are always rated at the same rate regardless of instance type.

Messages

The messages usage metric for a given billing period (calendar month) is determined as the maximum of:

  1. The total count of all data transactions to and in the Cumulocity platform, or
  2. The total count of messages processed through the MQTT Service.

A data transaction is defined as any authenticated API request with the intention to create, update, or process data within the Cumulocity domain model, including inventory objects, operations, measurements, events, and alarms. Transactions are counted regardless of processing mode, the details of which can be found in the Technical concepts section of the Cumulocity documentation. Transactions originate from both internal and external sources, including other Cumulocity applications, and are recorded via the platform’s Usage Statistics API.

The total count of MQTT messages is metered daily via the MQTT Service, with each day’s count contributing to the cumulative total for the billing period.

All counted transactions and messages are subject to the quotes listed in Service quotas. Usage that exceeds the listed limits may result in additional charges to ensure platform stability and prevent abuse.

For each billing period, the sum of daily MQTT message counts and the total count of data transactions are separately calculated. The greater of the two values is used as the final invoiced metric, rounded up to the nearest 100,000 units. In the case that one of the values is unable to be computed, the other value will be used for billing purposes.

Example

During a billing period, the sum of the daily values for each of the referenced components are as follows:

  • Data transactions = 1,192,000
    • Measurements created = 1,000,000
    • Events created = 20,000
    • Events updated = 5,000
    • Alarms created = 10,000
    • Alarms updated = 5,000
    • Operations created = 1,000
    • Operations updated = 1,000
    • Inventories created = 100,000
    • Inventories updated = 50,000
  • MQTT messages = 200,000

The total data transactions value is higher than that of the MQTT messages and therefore will be used as the final invoicing metric. To calculate the billable units, the total data transactions is rounded up to the nearest 100,000 units:

1,192,000 / 100,000 = 11.92

11.92 rounds up to 12 billable units of messages for the billing period.

GiB for Operational Data Store

The total volume of data stored in the Operational Data Store of the Cumulocity platform within a given billing period (calendar month). Data stored in the Operational Data Store is counted and exposed via the Usage Statistics API provided by the platform. The maximum daily value taken during the billing period will be used for invoicing purposes and is rounded up to the nearest gibibyte (GiB).

Tenant

Tenants are physically separated data spaces with a separate address (URL), with a specific set of users, a separate application management, and other individual functionality. Users in a single tenant share the same URL and the same data space. Add-ons that use the per-tenant billing metric will be invoiced based on the number of tenants that have the add-on deployed.

Cumulocity Compute Unit (CCU)

A Cumulocity Compute Unit (CCU) represents a standardized measure of computational resources consumed by microservices developed and deployed by the Customer, where 1 CCU is equivalent to 1 CPU core and 4 gibibytes (GiB) of memory. CCUs are calculated monthly by computing the daily average CPU resources used and daily average memory resources used (in bundles of 4 GiB) and taking the larger of the two values. This unit will be rounded up if fractional CPU cores or multiples of 4 GiB RAM are used. For example, 1.5 cores and 6 GiB RAM would be considered 2x compute units. Resource usage is first aggregated across all tenants before calculating the CCUs. A complete service description for Customer microservices can be found in the Service terms section of the Cumulocity documentation.

Example

The following aggregate metrics are calculated by summing up the daily resource limits for each custom microservice over the billing period (details on the resources field in the microservice manifest files can be found in the Cumulocity documentation. Custom microservices from all tenants across the Customer’s deployments are included in this calculation. Cumulocity provided microservices are not counted as part of the custom CCU calculation.

  • Aggregate CPU = 582,933
    • This metric is the total CPU time in millicores that is enabled for custom microservices. The metric is determined by the resource limits as written in the microservice manifest and the active subscription time of the microservice.
  • Aggregate Memory = 596,951
    • This metric is the total RAM allocation in megabytes that is enabled for custom microservices, as determined by the resource limits in the microservice manifest.

To calculate the CCU billing metric, these values are converted to daily average. For the purposes of this example, the billing period has 30 days.

  • AvgCPU = (582,933 millicores / 30 days) = 19,431.1 millicores/day
  • AvgRAM = (596,951 MB/ 30 days) = 19,898.37 MB/day

These daily average values are then put in the proper units aligned with the billable metric (CPU cores and GiB, respectively).

  • ccuCPU = (19,431.1 millicores/day) / (1000 millicores) = 19.43 CPU/day

    • where 1000 millicores = 1 core

  • ccuRAM = (19,898.37 MB/day) / (4294.97 MB) = 4.63 4GiB bundles/day

    • where 1 Gibibyte (GiB) = 1024 Mebibytes (MiB) = 1073.74 Megabytes (MB)
    • 4 GiB = 4 * (1073.74 MB) = 4294.87 MB

Then, the larger of the two values is rounded up to form the CCU billable metric. *ccuCPU = 19.43 > 4.63 = ccuRAM

19.43 rounds up to 20 billable units of CCUs in the billing period.

DataHub - GiB of data queried

Gibibyte (GiB) of data read from data lakes or other supported data sources by the licensed Software. Queries that fall below 10 MB will be rounded up to the minimum size of 10 MB. For invoicing purposes, any fractional values are rounded up to the nearest gibibyte.

DataHub - Memory unit

The total amount of memory available for use by DataHub nodes. A node is a physical or virtual machine or a container within the DataHub cluster that operates as either a co-ordinator node and/or an executor node. Both coordinator and executor nodes are required to run the DataHub add-on. A DataHub node must be deployed with no less than 16 GiB of memory. The memory allocation will be split between coordinator and executor nodes as determined necessary by the Cloud Services, with a minimum of 16 GiB for each node. The first unit will include 32 gibibytes (GiB) of memory. Subsequent units will be billed in increments of 16 GiB. For invoicing purposes, any fractional values are rounded up to the nearest 16 GiB unit.

Virtual Private Connection

Use by the Customer of the Cloud Services whose license metric is indicated as “Virtual Private Connection” above allows the creation of a total number of said connections via a redundant pair of site-to-site (“S2S”) tunnels between the Customer and the Supplier which does not exceed the licensed number indicated above. The reference to “Virtual Private Connection” refers to the use of a single redundant virtual private connection into the underlying instance of the Cloud Services operated by the Supplier at its hosting partners.

Database replica set

A Database replica set is for use with upscaling the Operational Store (database) of a single Cumulocity instance. A “replica set” includes up to 3 data-bearing nodes. A node can be deployed in a virtual machine, physical server, or container.