Fallback Pools, Now Visible in the Dashboard
When Cloudflare Load Balancers were first introduced three years ago, a key design question was how to handle traffic when every pool is down. The answer was a fallback pool: a “pool of last resort” that receives traffic when no other pools are detected as available. Even if the fallback returns an error, it gives the request a chance at success in case that pool is still serving traffic.
That fallback pool has now been added to the Load Balancing dashboard UI. Previously, customers had no way to visually confirm which pool was designated as the fallback, or whether one was set at all. This update resolves that ambiguity.
While creating or editing a Load Balancer in the Traffic app of the Cloudflare dashboard, you can now view which pool serves as the fallback and set any pool in the Load Balancer to that role. If no fallback is explicitly chosen, the last pool in the list is automatically assigned as the default—ensuring coverage in a worst-case scenario.
UI Refresh: De-modaling and Decluttering
The addition of the fallback pool prompted a broader update to the Load Balancing app. The main page has received a facelift, and most UI elements previously contained in modals have been moved to the main page area. The intent is to give users more context by leveraging the full page rather than a small, constrained modal. This change applies when creating or editing Load Balancers, and when managing monitors or pools.
In the updated interface, health status and its icon are combined to reduce visual clutter and make status visible at a glance. Toggle buttons across the UI are now smaller, freeing up margin space for the updated action buttons. The freed-up space also allowed tables to carry more information, helping users identify shared aspects of their Load Balancers.
Managing Shared Objects
Shared objects—Monitors and Pools—have posed a challenge for organizations with distributed teams using the same dashboard. A change made to a Monitor by one team could inadvertently affect another team’s Load Balancer.
To address this, Monitors and Pools now display a column showing which Load Balancers or Pools are currently using them. This visibility allows users to assess the impact of their edits before making them. For example, a team wanting to update a Monitor can now see which other Load Balancers may be affected, letting them proceed without needing to coordinate with another team first.
Beyond these columns, confirmation modals have been added that list all other Load Balancers or Pools that would be impacted by a change. In addition, edits to Monitors can now only be made from the Manage Monitors page. This separation is intentional: editing a shared object within the Load Balancer editing context could make a change seem scoped to that Load Balancer only, when in fact it applies globally.
Clearer Action Buttons
The transition to larger page areas also resolved a usability issue in the expanded Load Balancer table. When expanding a card to view details about Pools or Origins, the large X icon in the top right was commonly assumed to close the expansion. In fact, it deleted the Load Balancer entirely—a dangerous outcome for a user misreading the control.
The icon buttons have been replaced with text buttons labeled “Edit” and “Delete,” and the expanded-card layout has been updated. Text-based action cues leave less room for interpretation than icons, and the clarity is intended to prevent accidental deletions.
