Cloud Workflow
Does ZopNight manage Cloud Workflow?
Cloud Workflows bills per step executed, with internal steps cheaper than external HTTP calls, and charges nothing while a workflow sits idle. ZopNight inventories workflows via Cloud Asset Inventory and folds their execution spend into cost attribution. Cost problems come from step volume: polling loops and chatty external calls multiply billed steps.
Rules that fire on Cloud Workflow
No active rule family targets Cloud Workflow today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
Cloud Workflows orchestrates services and API calls in serverless, step-based executions billed per step. There is no idle charge, but chatty workflows with external steps can grow costs quickly.
Steps are the billing unit, and not all steps cost alike
A workflow execution is metered by the steps it performs, and the meter distinguishes two kinds: internal steps (assignments, conditionals, calls to Google Cloud services) and external steps, meaning HTTP calls to endpoints outside Google Cloud, which bill at a higher rate. A deployed workflow that never runs costs nothing at all; every unit of cost is earned by execution. That inversion matters for how waste shows up here: unlike a cluster or an instance, a Workflow cannot be idle-expensive. The exposure is the opposite shape. A workflow can execute far more steps than its job requires, multiplied by however often it is triggered.
Execution spend inside the attribution picture
ZopDev inventories workflows via Cloud Asset Inventory and includes their execution spend in cost attribution, so orchestration charges are tied to the named workflow producing them. With no idle state, there is nothing for ZopNight to schedule or stop; visibility is the value. Attribution answers the question step-based billing otherwise obscures: which of the dozens of small workflows in a project is generating the execution volume.
Designs that turn pennies into a line item
Step-count blowups follow known shapes. Polling loops are the canonical one: a workflow that checks an operation’s status every few seconds converts a long-running wait into thousands of billed steps per execution, where a callback or longer sleep interval would spend a handful. High-frequency triggers are the second. A workflow fired per event on a busy Pub/Sub topic multiplies its per-execution step count by millions of events. Third is external chattiness, where a sequence of outside HTTP calls bills at the premium external-step rate on every run.
Auditing execution volume in the console
Google Cloud console → Workflows lists each workflow with its region and revision. A workflow’s Executions tab shows run history and per-execution logs. The audit is to find the workflows with the highest execution counts and read one execution’s step log end to end, looking for loops that poll.