I'm parked on you

Everything I could decide myself is decided. What's left needs you. Each one carries the recommendation of the session that raised it — if you agree, pick it and press Done. A model's opinion, where there is one, appears on the card as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me. You don't need to open the session — pressing Done sends your answer back and it picks up.

1

In plain terms. Should we put a limit on how many copies of one background AppFolio job can run at the same time, or just keep watching it for now? That job keeps guest-card replies and rental applications up to date. Right now several copies are running at once, and some are taking over 10 minutes each — they used to take under a minute. Nothing has broken yet. But the guardrail that stops us from sending AppFolio too many requests doesn't know about all these copies running together, and that's the same problem that slowed AppFolio down a few weeks ago.

The full question, as raised

Lambda propflow-appfolio-sync-prod ConcurrentExecutions pileup alarm (>=12 for 5 datapoints; observed climbing 12->24 over ~15 min and still rising). The act_now cadence-class rule (rate(1 minute)) batches rental_applications + guest_cards + guest_card_messages into one invocation; per-invocation duration grew from ~20-240s at alarm onset to ~645-690s in the latest sample, approaching the 900s Lambda timeout. No Lambda Errors/Throttles metric hits, no 429s found in CloudWatch Logs or Sentry for this window. Root cause: AppfolioRequestBudget (src/lib/integrations/appfolio/request-budget.ts) is explicitly documented PROCESS-LOCAL — it paces requests per invocation/container and does not coordinate across concurrent invocations. As concurrency piles up, aggregate AppFolio request rate scales with the number of overlapping invocations — the same mechanism behind the 2026-09-12 429 storm (~258 req/min vs AppFolio's ~28/min ceiling) that got work_orders/renewals/vendors parked in schedules.json. A durable cross-process budget already exists (AppfolioAccountBudget, durable-account-budget.ts, PR #7911) but handler.ts's call sites all still use the process-local one. Options: (a) reserved-concurrency cap on the Lambda via the deploy pipeline (precedented in lambda/agent-runtime/deploy.sh put-function-concurrency) — throttled/dropped ticks are fine since every act_now job is documented self-healing/idempotent; (b) park one of the three act_now jobs like the Sept 12 incident, pending a proper fix (wiring the durable budget); (c) wait — prior alarm firings (09-12, 09-13 x2) self-cleared within under an hour, though none previously grew this large or this fast.

The session raising this recommends: Add a safety cap now — updates may lag briefly
Reversible (a Lambda concurrency setting, not a code change), matches an existing deploy-script pattern, and every job on this cadence is already built to pick up a skipped run on the next minute.
Tried first, unsuccessfully: Pulled CloudWatch concurrency/error/throttle metrics and alarm history, checked Sentry and CloudWatch Logs for AppFolio 429s (found none), read the EventBridge cadence-class config and the job dispatcher, and traced the AppFolio rate limiter — it documents itself as process-local and names the exact durable replacement that isn't wired in yet. Didn't apply a concurrency cap myself because the last time this account risked an AppFolio overload, pausing/throttling these same jobs was explicitly your call, made by hand four times.

Add a safety cap now — updates may lag brieflythe raiser's pick Hold off — keep watching for now Pause the least-critical part until you review it I'm not sure — go find out

5ee74e86 is parked on this.

Pick an option above, then press Done.