# Ensure a Consumption Alert Is Set on Public Cloud Projects

- Source: https://support.icompaas.com/support/solutions/articles/a_1791826037908777-ensure-a-consumption-alert-is-set-on-public-cloud-projects
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [OVH Cloud](https://support.icompaas.com/support/solutions/c_1791819364512367) › [checks](https://support.icompaas.com/support/solutions/folders/f_1791819376721251)
- Last updated: 2026-10-12
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure each Public Cloud project has a consumption alert that sends an email when the project's monthly spend reaches a set threshold, so unexpected costs are noticed quickly.

**Rationale**

Public Cloud is billed on usage, and costs can grow quickly because of mistakes, runaway autoscaling, or a compromised account used for crypto-mining. Without an alert, this may only be noticed when the invoice arrives. A consumption alert gives early warning so action can be taken.

**Impact**

-   Unexpected spending is noticed early
    
-   Helps detect misuse of the project
    
-   Thresholds must be updated as normal usage changes
    

**Default Value**

By default, no consumption alert is set on Public Cloud projects.

**Pre-Requisites**

-   Permission to manage the Public Cloud project
    
-   Access to the OVHcloud API console
    
-   An agreed monthly spending threshold
    

**Test Plan**

1.  Open the OVHcloud API console at [https://eu.api.ovh.com/console/](https://eu.api.ovh.com/console/) (or your region's console) and log in.
    
2.  Run GET /cloud/project/{serviceName}/alerting, replacing {serviceName} with your project ID.
    
3.  For each returned ID, run GET /cloud/project/{serviceName}/alerting/{id} and check the email, monthlyThreshold, and delay values.
    
4.  If no alert exists, follow the implementation steps.
    

**Implementation Steps**

1.  Open the OVHcloud API console at [https://eu.api.ovh.com/console/](https://eu.api.ovh.com/console/) (or your region's console) and log in.
    
2.  Run POST /cloud/project/{serviceName}/alerting with: email (the address to notify), monthlyThreshold (the monthly amount in your account currency), and delay (seconds between two alerts, for example 3600).
    
3.  Run GET /cloud/project/{serviceName}/alerting to confirm the alert was created.
    
4.  With Terraform, you can use the ovh\_cloud\_project\_alerting resource instead.
    

**Backout Plan**

1.  Run PUT /cloud/project/{serviceName}/alerting/{id} to change the threshold, or DELETE /cloud/project/{serviceName}/alerting/{id} to remove the alert.
    

**Reference**

-   [https://www.pulumi.com/registry/packages/ovh/api-docs/cloudproject/alerting](https://www.pulumi.com/registry/packages/ovh/api-docs/cloudproject/alerting)
    
-   [https://help.ovhcloud.com/csm/en-public-cloud-compute-control-panel?id=kb\_article\_view&sysparm\_article=KB0050405](https://help.ovhcloud.com/csm/en-public-cloud-compute-control-panel?id=kb_article_view&sysparm_article=KB0050405)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.