Skip to main content

Hello Everyone,

I am considering the implementation of "Delay Playbook v2" to manage SLA requirements in my project. Before proceeding, I would like to gain insights into its resource consumption and overall efficiency.

Specifically, I am curious about:

  1. The resource demands when deploying "Delay Playbook v2."
  2. Its performance when running 100 playbooks concurrently.

Any experiences, benchmarks, or recommendations you can share would be greatly appreciated.

Thank you in advance for your assistance!

Hi @deep0x00 


This link might be helpful: https://cloud.google.com/chronicle/docs/soar/admin-tasks/advanced/service-limits#playbook-limits 

Hello @ErikaB 
Thank you for sharing this link. I have gone through it previously. 
I was trying to find a way in Google SecOps to delay a playbook action.
That's when I found there is a Delay Playbook action in Tools integration.
I am thinking of using it as SLA. Based on this I want to perform some actions like sending messages in Google chats if sla is missed.

So wanted to ask in the community if anyone has tried something similar.

Hi @deep0x00 


There is another community thread on delayed playbook actions and using parallel actions.  https://www.googlecloudcommunity.com/gc/SecOps-SOAR/Delay-playbook-action-issue/m-p/785382

Hello @ErikaB 
Thank you for sharing this link. I have gone through it previously. 
I was trying to find a way in Google SecOps to delay a playbook action.
That's when I found there is a Delay Playbook action in Tools integration.
I am thinking of using it as SLA. Based on this I want to perform some actions like sending messages in Google chats if sla is missed.

So wanted to ask in the community if anyone has tried something similar.



To my knowledge, DelayV2 is an async Action, this means it sets a future cron call back to pick up and retry.  In this gap the resources are effectively unlocked.

This is in contrast to something like the python command 'sleep' that consumes resources in the time window.

It should scale quite well, but even 'quite well' has limits 🙂 lol


To my knowledge, DelayV2 is an async Action, this means it sets a future cron call back to pick up and retry.  In this gap the resources are effectively unlocked.

This is in contrast to something like the python command 'sleep' that consumes resources in the time window.

It should scale quite well, but even 'quite well' has limits 🙂 lol


Thank you @SoarAndy 
Will try to implement this and update my feedback here🙂

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.