GCP Workflow keeps executing after scheduler job and triggers are removed

Google Cloud Integration Services
,
1

A workflow in GCP Workflows keeps executing for a resource that has been deactivated in one of our production google cloud project. The Cloud Scheduler job for it has been deleted and no triggers exist, but new executions are still appearing which we don’t want. Need help identifying what is triggering these executions.

For example, the workflow is making POST calls to an endpoint like /v1/.../init-sync for the deactivated resource on a scheduled interval, even though no scheduler job or trigger is configured for it anymore. The executions seem to be recurring and not just a one-off leftover run.

2

Hi @Shravan_Das, welcome to the community! We appreciate you reaching out :smiley:

While our community reviews your post, you may want to check out our Knowledge Hub for helpful patterns and best practices on event-driven architectures.

Please feel free to share any additional details, such as logs or configuration snippets (ensuring you mask any sensitive project-specific data); we will make sure to keep this thread on our radar!

4

Hi @AlexET
Thanks for getting back.

I can share some screenshots showing the workflow being triggered in Log Explorer. However, when I check the Workflows section, I don’t see any schedule or trigger configured for that workflow since it was deleted previously. Additionally, in the Workflow Executions tab, there are no executions listed for that specific workflow.

If you need any specific information such as workflow IDs, project details, or other identifiers, I can share them either internally or via email.

My main question is whether this could be a bug. If there is no configured workflow trigger or schedule associated with that workflow, why is it being marked as invoked or triggered?

image

image
image1799×840 42.4 KB

6

Hello,

It can be challenging when executions continue to run even after you have deleted their associated schedules. Let’s walk through some potential causes and checks to help you pinpoint what is triggering these recurring runs:

  • Check Cloud Audit Logs in Cloud Logging: This is the most direct way to identify the caller. In Cloud Logging, search for the log entries associated with your workflow executions. Look at the Cloud Audit Logs to find the principalEmail or identity that is calling the executions.create API. This will tell you if the triggers are originating from an automated service account, another user, or a cross-project service.

  • Review Cross-Project Triggers: Check if there are active triggers—such as Cloud Scheduler, Cloud Pub/Sub, or Eventarc—configured in another Google Cloud project that target your workflow.

  • Inspect Cloud Tasks: If your workflow is initiated via Cloud Tasks, there might be scheduled or failed tasks still residing in a task queue that are repeatedly retrying the executions.

  • Look for Parent Workflows or Integrations: Ensure that there isn’t a parent integration workflow or another parent Workflow triggering this execution (for instance, via a Workflows - Execute task or a For Each Loop).

  • Verify Apigee, API Gateway and HTTP Endpoints: If the workflow is exposed via Apigee or API Gateway or as an HTTP-triggered endpoint, check if an external client or application is still sending recurring POST requests to that endpoint.

To help narrow down the cause, could you share a few more details so we can assist you better?

  1. How was this workflow originally configured to be triggered (e.g., via Eventarc, a Pub/Sub push subscription, or directly via HTTP)?

  2. When you view the Execution Logs in the Google Cloud console, what identity or service account is shown as the creator of the run?

As recommended in our community guides, we also suggest checking the official Google Cloud documentation for Cloud Logging and Workflows as you run these checks.

Best regards,

Maria