Post-mortem: Flows feature flag incident, May 7, 2026
We promise that you control when changes reach your non-dev environments. Last Thursday, that wasn’t true. Here’s what happened and what we’re doing about it.
What happened
Flows is a significant new capability developed over several months behind a feature flag. To stage the rollout, we recently added version-based targeting to our feature flag system. The new logic evaluated against the solution’s current Appfarm Create version rather than against the version of the specific environment. Because dev environments upgrade automatically each week, flag activation became coupled to our release schedule rather than to customer-initiated deploys.
This inverts the control model the platform promises, and it is the failure mode we must most aggressively design against.
The feature ran in our Early channel the previous week without observable issues. The bug surfaced when we rolled to Standard, where most customers run. Stable was unaffected.
Impact
Most customers saw no observable change. Some saw behavioral differences in their applications, which generated the support tickets that led us to detect the issue. Because the bug changed behavior rather than causing outright failures, we do not have a reliable signal for the full set of affected solutions.
Timeline (CET), Thursday May 7
- Overnight: Standard channel upgrade rolls to dev environments
- Morning: Support tickets increase; investigation begins
- 10:47: Flows feature flag disabled platform-wide
- 11:15: Further rollout halted
- Through the day: Support works directly with affected customers
What we’re changing
- Full audit of every active feature flag and its activation logic
- Wider rollout on internally controlled solutions before releasing to customers
- Feature flag targeting will evaluate against the targeted environment’s version, not the solution’s current version
- Stricter review and testing requirements for flag logic that can affect non-dev environments
- A canary phase within the Standard channel for high-impact changes. Early-to-Standard has been a single step; for changes of significant scope we will roll out to a subset of Standard first and observe before continuing
We are committing to making this specific class of failure substantially harder to introduce: platform-initiated changes should not reach customer-controlled environments without the customer initiating the deploy.