Detect suspicious cloud behavior before spotting the cost

The system learns the normal spending behavior of each billing account (its typical hourly and daily patterns) and constantly compares current spending against this baseline. It marks statistically significant deviations: sudden hourly spikes, daily increases multiple times above the average, sustained growth, or projected monthly budget overruns, and then classifies each event by severity (Warning/ Critical) so that the most serious risks appear first. Because the baseline is calculated per account, an amount normal for one customer might be an anomaly for another. We monitor new accounts with large budgets using a separate detection system from the very first hours—without waiting for a history to build up.

No. Static thresholds are supported and still useful, but the core is behavioral—each account is measured against its own learned baseline, not a single fixed number. This allows it to catch a significant change that a rigid limit would miss, i.e., spikes just below the threshold or costs growing gradually without crossing a hard limit, while still respecting your configured budgets.

No. Cloud Anomaly Detector focuses on detection, context, notification, and escalation—it does not turn off or modify resources itself. Any change in the environment, e.g., rotating a key, limiting an account, or stopping a workload, is a defined action involving a human. The scope of what FOTC can perform is agreed upon individually, so nothing changes without a clear mandate.

Monitoring runs continuously, around the clock, including at night and on weekends when incidents are easiest to overlook. The human response—who acts, how quickly, and through which channel (chat, CRM task, phone, or pager)—depends on the scope of service and may be covered by a separate SLA. We consciously do not promise a single fixed response time here, as it is set to match actual agreement monitoring—patients. We also monitor ourselves: the freshness of Google’s billing data and the health of our own detector. A halted billing export alerts us just as much as a customer anomaly—silence in the data never means peace of mind for us.

It does not replace but supplements, so we recommend keeping native alerts. Google Cloud budget alerts are an important element, but the alert itself is just a notification. FOTC adds an operational layer around it: behavioral detection against the baseline, severity classification, customer and account context, clearly assigned responsibility, an escalation path, and (in an expanded scope) expert response support.

Cloud Anomaly Detector reacts quickly to sudden or significant anomalies, usually within its detection cycle. Two honest notes: Google Cloud billing data can have reporting delays, so the exact time depends on when consumption is reported, and a newly connected account needs a short learning period before a reliable baseline is established. It is also less suited for very slow, multi-week drift where the change in a single cycle is small—such a pattern is better caught by periodic cost reviews. We explicitly report accounts that we cannot yet evaluate (e.g., due to an insufficient history) as “unrated,” rather than showing them as “no anomalies.” You always know what is being monitored and what is not.

Yes. The Cloud Anomaly Detector supports multiple billing accounts of various sizes and in different currencies from a single console and maps each anomaly to the correct customer, account, and owner. This ensures a large or multi-entity environment remains visible in one place rather than scattered across separate dashboards, and it’s clear who should react when a change occurs.n one place rather than scattered across separate dashboards, and it’s clear who should react when a change occurs.

Yes, as part of the Cloud Care service or a separate Cloud Security Audit. This can include a review of IAM permissions and roles, service accounts and their keys, potential API key exposure, billing alert configuration, and escalation procedures. The goal is not just to resolve the current event but also to provide specific recommendations to reduce the risk of the same type of incident recurring.

LLMjacking is a new phenomenon that involves the illegal acquisition of cloud credentials—not to steal data, but to obtain access keys to paid language models in order to use them at the victim’s expense or resell them. As part of the Cloud Anomaly Detector service, we regularly review whether your projects have spending limits for AI services (Gemini, Gemini Enterprise Agent Platform)—the primary targets of key theft—and recommend a limit based on actual usage. We also configure budgets with threshold alerts. Limits and alerts help quickly detect an attack, but they do not block it—nothing shuts down automatically, because every change in the environment is a human decision.

Yes, you don’t need to have a billing account with FOTC. You can connect Cloud Anomaly Detector to any environment: all you need is a standard billing export to BigQuery and read access for our service account—you can grant it with just two clicks. We don’t install anything to run the service, and we don’t touch your resources—we only see billing data.