Cloud Run concurrency target GA: a Sume webhook receiver sizing
Cloud Run's custom target concurrency and CPU scaling is GA. Size a Sume webhook receiver around the 10 second attempt timeout and 10 retries.

For a Sume webhook receiver on Cloud Run, set the custom target concurrency high enough that bursts of deliveries do not queue behind each other, and make the handler return in well under 10 seconds. Google's release notes list scaling controls with custom target CPU or concurrency as generally available on September 29, 2026. Sume gives each delivery attempt a 10 second timeout and does not follow redirects.
What Sume sends to your service
Sume retries up to 10 attempts. Job webhooks are spaced at a fixed 30 seconds. Run webhooks (action.run.terminal, format.run.terminal, agent.run.terminal) back off exponentially, bounded by one hour and by any Retry-After you return.
| Property | Job webhooks | Run webhooks |
|---|---|---|
| Attempts | 10 | 10 |
| Timeout per attempt | 10 s | 10 s |
| Spacing | Fixed 30 s | Exponential with jitter, up to 1 h |
| Dedupe key | job_id | run_id or request_id |
| Redirects | Not followed | Not followed |
Why concurrency matters here
Cloud Run starts instances to meet your concurrency target. If a handler does slow work, such as downloading a video or calling a database, each request holds a slot. A burst of completions after a bulk run can exceed capacity, a delivery misses its 10 second budget, and the retry arrives later.
Keep the handler tiny: verify the signature, write the event id and payload to a store, return 200, and process asynchronously. A run receipt over 1 MiB arrives with payload: null and error.code of payload_too_large, so fetch result_url in the background.
Settings to review
These are choices, not Google defaults.
- Concurrency target: lower for CPU-heavy handlers, higher for pure I/O.
- Minimum instances: keep one warm if a cold start could approach the 10 second timeout.
- Request timeout: no need to exceed Sume's 10 seconds.
- Authentication: the endpoint must be public HTTPS for Sume, so verify the HMAC signature in code instead of relying on IAM.
Verify the signature in the container
Use the signing secret from the dashboard Webhooks tab and store it in Secret Manager under SUME_COM_WEBHOOK_SIGNING_SECRET. During a 24 hour rotation the header holds several sume-v1= entries, so accept any match.
import hashlib
import hmac
import os
import time
def verify(raw: bytes, ts: str, sig_header: str, secret: str) -> bool:
if not secret:
raise ValueError("signing secret is empty")
if abs(time.time() - int(ts)) > 300:
return False
mac = hmac.new(secret.encode(), ts.encode() + b"." + raw, hashlib.sha256)
want = "sume-v1=" + mac.hexdigest()
return any(hmac.compare_digest(p.strip(), want) for p in sig_header.split(","))
if __name__ == "__main__":
secret = os.environ.get("SUME_COM_WEBHOOK_SIGNING_SECRET", "")
body = b'{"ok":true}'
ts = str(int(time.time()))
sig = "sume-v1=" + hmac.new(secret.encode(), ts.encode() + b"." + body, hashlib.sha256).hexdigest()
print(verify(body, ts, sig, secret))
Sources
Related posts
More in Developers
- Cloud Scheduler retries and a static Idempotency-Key: the replay trap
A fixed Idempotency-Key header on a Cloud Scheduler POST replays the first Sume run forever. Derive the key per tick, or use Sume Actions for schedules.
- Cloud Tasks batch create is GA: one Sume idempotency key per task
Cloud Tasks batch create went GA on Sep 30, 2026. Give every task its own Sume Idempotency-Key so a batch retry never doubles a paid generation.
- Cloudflare Worker roles: let an agent deploy a Sume webhook receiver
Cloudflare's four Worker roles let an agent token deploy a Sume webhook receiver without delete rights. Which role to give it and what Sume still needs.
- Cloudflare Queues limits vs Sume queue_full 429: who retries?
Cloudflare Queues allows 100 retries and 24h delaySeconds. Sume answers 429 queue_full or rate_limited. How to back off in a consumer without duplicate jobs.
Written by Sume