diff --git a/api-reference/origin-errors/index.mdx b/api-reference/origin-errors/index.mdx
index ca13b418..b2331c00 100644
--- a/api-reference/origin-errors/index.mdx
+++ b/api-reference/origin-errors/index.mdx
@@ -42,4 +42,8 @@ The API returns logs with the following error codes:
| `http_invalid_compression` | Invalid compression in response |
| `network_socket_exception` | Network socket exception |
| `network_io_error` | Network I/O error |
+| `ssl_error` | TLS handshake with the origin failed (invalid origin certificate) |
| `notfound_localdb` | Not found in local database |
+| `origin_url_malformed` | The configured origin URL is malformed |
+| `loadbalanced_origin_failure` | A load balancer origin failed |
+| `error` | Unknown or unclassified origin error |
diff --git a/cdn/limits.mdx b/cdn/limits.mdx
index aae24b0c..32155f71 100644
--- a/cdn/limits.mdx
+++ b/cdn/limits.mdx
@@ -37,6 +37,15 @@ All limits can be increased upon request by contacting support with details abou
---
+## Load Balancer Limits
+
+| Limit | Default |
+|--------------------------------------|--------|
+| Max Origin Groups per Load Balancer | 10 |
+| Max Origins per Load Balancer (across all groups) | 50 |
+
+---
+
If you require higher limits on any of the above, please contact support with your use case and expected scale. Most limits can be adjusted.
diff --git a/cdn/load-balancer/health-and-failover.mdx b/cdn/load-balancer/health-and-failover.mdx
new file mode 100644
index 00000000..896677b3
--- /dev/null
+++ b/cdn/load-balancer/health-and-failover.mdx
@@ -0,0 +1,56 @@
+---
+title: Health and Failover
+description: How origin health is monitored and how the Load Balancer fails over when an origin becomes unavailable.
+---
+
+The Load Balancer combines two layers of protection: active health checks that remove failing origins from rotation globally, and passive failure detection that reacts to problems observed in live traffic. Together they route traffic around outages without any manual intervention.
+
+## Health checks
+
+Health checks are configured per origin group and are disabled by default.
+
+| Setting | Default | Description |
+|---------|---------|-------------|
+| Enabled | disabled | Turns active health monitoring on for all origins in the group. |
+| Path | `/` | The path probed on each origin, up to 500 characters. |
+
+When enabled, the bunny.net monitoring network periodically sends a `GET` request to the configured path on every origin in the group. Each origin is either **Healthy** or **Degraded**:
+
+- Healthy origins participate in routing normally.
+- Degraded origins are removed from rotation across the entire edge network until the health check passes again.
+
+The current health status of every origin is visible in your Load Balancer configuration and via the API.
+
+
+ Point the health check path at a lightweight endpoint such as `/healthz` rather than a heavy page. A good health endpoint also verifies the services your application depends on, such as its database or cache, and returns an error when any of them is unavailable. This lets an origin that is still serving traffic but cannot function correctly pull itself out of rotation until it is fully healthy again.
+
+
+
+ Disabling health checks on a group immediately resets all of its origins to Healthy, so any origin that was removed from rotation starts receiving traffic again.
+
+
+## Passive failure detection
+
+Independently of health checks, every edge server tracks failures it observes in live traffic. An origin that fails repeatedly in a short period is temporarily taken out of rotation on that edge server and automatically re-tested. A successful response puts the origin back into full rotation.
+
+This layer works even with health checks disabled, and reacts faster than any active probe can, but its view is local to each edge server.
+
+## Failover
+
+For every request, the routing methods produce a complete ordered list of eligible origins (see [Routing methods](/cdn/load-balancer/routing)). The request goes to the first origin; if that fails, the Load Balancer moves down the list:
+
+- **Connection-level failures** (DNS errors, refused connections, TLS failures, timeouts) always trigger failover to the next origin. Nothing reached your origin, so any request can be safely retried elsewhere.
+- **HTTP 5xx responses from the origin** trigger failover only for requests that are safe to replay: requests without a body, excluding `POST`, `PUT`, and `PATCH`. For non-replayable requests, the origin's own error response is returned to the client instead, so a state-changing request is never delivered to two origins.
+- Failover stops as soon as response data has been streamed to the client.
+
+The failover chain is time-limited, so a request fails fast rather than working through a long list of slow origins indefinitely. Your Pull Zone's own origin retry settings (retry count, delay, and conditions) apply to the final origin in the chain.
+
+### When everything is failing
+
+The Load Balancer prefers degraded service over no service. If no origin passes the health filters, a request is still attempted against unhealthy origins as a last resort rather than being failed outright. Only origins and groups you have explicitly disabled are never used.
+
+If every eligible origin has been tried and failed, the client receives a `502 Bad Gateway` response.
+
+## Logging failures
+
+Each failed origin attempt is recorded in your Pull Zone's [origin error logs](/cdn/logging/origin-errors) with the specific cause (such as `dns_lookup`, `http_timeout`, or `ssl_error`), or `loadbalanced_origin_failure` as a general fallback. Per-origin failure counts, broken down by status code, are also available in [statistics](/cdn/load-balancer/statistics).
diff --git a/cdn/load-balancer/index.mdx b/cdn/load-balancer/index.mdx
new file mode 100644
index 00000000..d8bd00c6
--- /dev/null
+++ b/cdn/load-balancer/index.mdx
@@ -0,0 +1,77 @@
+---
+title: Load Balancer
+sidebarTitle: Overview
+description: Distribute Pull Zone traffic across multiple origins with configurable routing, health checks, and automatic failover.
+---
+
+The Load Balancer distributes uncached requests from your Pull Zones across multiple origin servers. Each request is routed using a configurable balancing method, origin health is monitored continuously, and traffic automatically fails over to healthy origins when a server becomes unavailable.
+
+A Load Balancer is a reusable routing policy that lives on your account. It does not have its own hostname. Instead, you attach it to one or more Pull Zones, and the CDN edge applies it whenever a request needs to be fetched from an origin. Requests served from the CDN cache never reach the Load Balancer.
+
+## How it works
+
+```mermaid
+flowchart LR
+ Client --> Edge[CDN edge]
+ Edge -->|cache MISS| LB[Load Balancer]
+ LB --> GroupA[Origin group A]
+ LB -.->|failover| GroupB[Origin group B]
+ GroupA --> O1[Origin 1]
+ GroupA --> O2[Origin 2]
+ GroupB --> O3[Origin 3]
+```
+
+When a request misses the cache, the edge server builds an ordered list of all eligible origins: it first orders your origin groups (by priority, then by the group balancing method), then orders the origins inside each group (by the group's origin balancing method). The first origin in the list receives the request, and the rest of the list is the failover order if it fails.
+
+## Concepts
+
+| Concept | Description |
+|---------|-------------|
+| Load Balancer | An account-level routing policy with a name, a group balancing method, and optional sticky sessions. Attachable to any number of Pull Zones. |
+| Origin group | A set of origins treated as one unit for balancing and failover. Each group has its own balancing method, weight, priority, and health check settings. |
+| Origin | A single backend: an HTTP(S) server, a Storage Zone, an Edge Script, or a Magic Containers endpoint. |
+
+## Connect a Pull Zone
+
+
+
+ Create a Load Balancer with a unique name and choose how traffic is distributed between origin groups.
+
+
+ Add at least one origin group, then add your origins to it. See [Origins and origin groups](/cdn/load-balancer/origins) for the available origin types and settings.
+
+
+ Set the Pull Zone's origin type to **Load Balancer** and select your Load Balancer. The Pull Zone's own origin URL is no longer used; each origin defines its own destination.
+
+
+
+A single Load Balancer can be attached to multiple Pull Zones, and all attached zones share the same routing policy. Switching a Pull Zone back to a different origin type detaches it again. A Load Balancer cannot be deleted while any Pull Zone still uses it as its origin.
+
+All configuration is also available through the API. See the [API reference](/api-reference/core) for the full endpoint documentation.
+
+## Explore
+
+
+
+ Origin types, connection settings, and limits.
+
+
+ How origin groups and origins are selected, weights, and priority tiers.
+
+
+ Pin returning visitors to the same origin using cookies.
+
+
+ Health checks, failure detection, and automatic failover behavior.
+
+
+ Per-origin traffic, latency, and failure metrics.
+
+
+ Monthly fee, included requests, and overage billing.
+
+
+
+
+ Looking for DNS-level load balancing across multiple record values? That is a separate feature of Bunny DNS. See [DNS load balancing](/dns/records#load-balancing).
+
diff --git a/cdn/load-balancer/origins.mdx b/cdn/load-balancer/origins.mdx
new file mode 100644
index 00000000..9a7471a1
--- /dev/null
+++ b/cdn/load-balancer/origins.mdx
@@ -0,0 +1,78 @@
+---
+title: Origins and Origin Groups
+description: Configure the origin groups and origins behind your Load Balancer, including origin types, connection settings, and limits.
+---
+
+A Load Balancer contains one or more origin groups, and each origin group contains one or more origins. Groups let you organize origins into units that are balanced and failed over together, for example a primary datacenter and a backup datacenter.
+
+## Origin groups
+
+| Setting | Default | Description |
+|---------|---------|-------------|
+| Name | required | Unique within the Load Balancer, up to 100 characters. |
+| Enabled | enabled | Disabled groups receive no traffic at all, including failover traffic. |
+| Weight | 100 | Relative share of traffic (1 to 255) when the group method is Weighted Random. |
+| Priority | 100 | Failover tier. Groups with a lower priority value are tried first; higher tiers only receive traffic when every origin in the lower tiers has failed. |
+| Balancing method | Round Robin | How origins inside this group are selected. See [Routing methods](/cdn/load-balancer/routing). |
+| Latitude / Longitude | 0, 0 | The group's geographic location, used by the Geo Location group balancing method. |
+| Health check | disabled | Active health monitoring for the group's origins. See [Health and failover](/cdn/load-balancer/health-and-failover). |
+
+## Origins
+
+Every origin has the following settings, plus type-specific configuration:
+
+| Setting | Default | Description |
+|---------|---------|-------------|
+| Enabled | enabled | Disabled origins receive no traffic at all, including failover traffic. |
+| Weight | 100 | Relative share of traffic (1 to 255) when the group's method is Weighted Random. |
+| Type | Standard | One of the origin types below. |
+
+### Origin types
+
+| Type | Description |
+|------|-------------|
+| Standard | Any HTTP or HTTPS server, defined by an origin URL. |
+| Storage | A bunny.net [Storage Zone](/storage). |
+| Edge Script | A bunny.net [Edge Script](/scripting) of type CDN. |
+| Magic Containers | A [Magic Containers](/magic-containers) CDN endpoint. Anycast endpoints are not supported; add those as a Standard origin using the endpoint's IP address and port instead. |
+
+### Taking origins out of rotation
+
+Disable an origin to remove it from rotation without deleting its configuration. Typical reasons:
+
+- **Scheduled maintenance or deployments**: disable the origin before you start, so no new requests are routed to it while you work, then re-enable it when you are done.
+- **Incident response**: if you identify a problem with a server, disabling it removes it from rotation immediately while you investigate, without waiting for health checks to react.
+- **Staging a new server**: add the origin disabled, then enable it once the server is ready to receive traffic.
+
+Disabling an entire origin group works the same way and is useful for taking a whole location or datacenter offline at once. Disabled origins and groups receive no traffic under any circumstances, including failover.
+
+## Standard origin settings
+
+### Origin URL
+
+The origin URL must use HTTP or HTTPS, and can include a port and a path prefix that is prepended to every request path. For example, with an origin URL of `https://origin1.example.com:8443/api`, a client request for `/users` is fetched from `https://origin1.example.com:8443/api/users`.
+
+### Host header
+
+The `Host` header sent to a Standard origin is resolved in this order:
+
+1. If the Pull Zone has **Forward Host Header** enabled, the client's original host is forwarded.
+2. Otherwise, the origin's **Host Header** setting is used, if set.
+3. Otherwise, the hostname from the origin URL is used.
+
+### TLS verification
+
+When **Verify SSL** is enabled (the default), the edge validates the origin's TLS certificate and rejects the connection if validation fails. Disable it only if your origin uses a self-signed or otherwise invalid certificate.
+
+## Limits
+
+| Limit | Default |
+|-------|---------|
+| Origin groups per Load Balancer | 10 |
+| Origins per Load Balancer (across all groups) | 50 |
+
+Contact support if you need higher limits for your use case.
+
+## Updating configuration
+
+Configuration changes typically propagate to the edge network within seconds. Note that changing a Load Balancer can also reset active [sticky sessions](/cdn/load-balancer/sticky-sessions).
diff --git a/cdn/load-balancer/pricing.mdx b/cdn/load-balancer/pricing.mdx
new file mode 100644
index 00000000..c9bad5d4
--- /dev/null
+++ b/cdn/load-balancer/pricing.mdx
@@ -0,0 +1,34 @@
+---
+title: Load Balancer Pricing
+sidebarTitle: Pricing
+description: How Load Balancers are billed, including the monthly fee, included requests, and overage rates.
+---
+
+Each Load Balancer is billed a flat monthly fee that includes a generous request allowance, with a per-million rate for requests beyond it.
+
+| Item | Price |
+|------|-------|
+| Monthly fee, per Load Balancer | \$9.50 |
+| Included requests, per Load Balancer per month | 50 million |
+| Additional requests | \$0.65 per million |
+
+## What counts as a request
+
+Only requests that actually reach the Load Balancer are counted: cache misses and other requests that require an origin. Requests served from the CDN cache are not counted, so a well-cached zone typically sends only a small fraction of its total traffic through the Load Balancer.
+
+## How billing works
+
+- **Billing is per Load Balancer.** Attaching one Load Balancer to five Pull Zones incurs a single monthly fee, and requests from all attached zones share the same 50 million request allowance.
+- **The monthly fee is prorated.** You only pay for the time a Load Balancer exists: creating one mid-month charges the remainder of the month, and deleting one stops the charge immediately.
+- **The request allowance resets monthly.** Usage counts from the first of each calendar month (UTC), and every month starts with a fresh 50 million included requests. The allowance is per calendar month and unused requests do not roll over.
+- **Overage is exact.** Additional requests are billed at \$0.65 per million, prorated to the actual request count rather than rounded up to whole millions.
+
+For example, a Load Balancer that handles 62 million origin requests in a full month costs \$9.50 plus 12 million additional requests at \$0.65 per million, or \$17.30 in total.
+
+
+ The monthly fee applies from the moment a Load Balancer is created, even before it is attached to a Pull Zone. Delete Load Balancers you no longer use.
+
+
+## Tracking usage
+
+Month-to-date request usage against the included allowance is available per Load Balancer in the dashboard and through the usage API, including the exact time the allowance resets. See [Statistics](/cdn/load-balancer/statistics) for the full monitoring options.
diff --git a/cdn/load-balancer/routing.mdx b/cdn/load-balancer/routing.mdx
new file mode 100644
index 00000000..a2904483
--- /dev/null
+++ b/cdn/load-balancer/routing.mdx
@@ -0,0 +1,71 @@
+---
+title: Routing Methods
+description: How the Load Balancer selects an origin group and an origin for each request.
+---
+
+Routing happens in two independent steps. First, the Load Balancer's **group balancing method** decides which origin group handles the request. Then, that group's **origin balancing method** decides which origin inside the group receives it.
+
+The selection does not just pick a single origin. It produces a complete ordered list of all eligible origins, so the balancing methods also determine the failover order when an origin fails. See [Health and failover](/cdn/load-balancer/health-and-failover) for how that list is consumed.
+
+## Group balancing methods
+
+Set on the Load Balancer, this method decides how traffic is distributed between origin groups that share the same priority.
+
+| Method | Behavior |
+|--------|----------|
+| Round Robin (default) | Cycles through the groups sequentially. |
+| Weighted Random | Selects a group randomly, in proportion to each group's weight. |
+| Geo Location | Selects the group geographically closest to the edge server handling the request, based on each group's configured latitude and longitude. |
+| Lowest Average Latency | Selects the group whose origins currently have the lowest average response latency. |
+
+
+ Geo Location routing measures distance from the CDN edge server that received the request. Because clients are already routed to their nearest edge location, this closely tracks client geography.
+
+
+## Origin balancing methods
+
+Set per origin group, this method decides how traffic is distributed between the origins inside the group.
+
+| Method | Behavior |
+|--------|----------|
+| Round Robin (default) | Cycles through the origins sequentially. |
+| Weighted Random | Selects an origin randomly, in proportion to each origin's weight. |
+| Least Connections | Routes to the origin with the fewest requests currently in flight. |
+| Latency | Routes to the origin with the lowest response latency. |
+
+Latency is measured from real traffic as the time from sending a request to receiving the first byte of the response, weighted toward the most recent samples. Origins without recent measurements are re-tested automatically, so a recovered origin finds its way back into rotation without manual intervention.
+
+Some common choices:
+
+- **Round Robin** for identical servers that should share traffic evenly.
+- **Weighted Random** for servers with different capacities, or for shifting a small share of traffic to a new server before rolling it out fully.
+- **Least Connections** for applications with long-running or highly variable requests, where counting in-flight work balances better than counting requests.
+- **Latency** to favor whichever origin responds fastest from each edge location. Because the measurement includes the network round trip, this naturally prefers origins closer to where the traffic is, while still routing around a nearby server that is slow or overloaded.
+
+## Priority and failover tiers
+
+Origin groups are always processed in ascending priority order (lower value first). All origins from the lowest-priority tier appear in the failover list before any origin from the next tier, so higher tiers act as pure backup: they only receive traffic once every origin in the tiers before them is unavailable or has failed.
+
+Groups that share the same priority value form one tier and are balanced against each other using the group balancing method. A typical setup:
+
+| Group | Priority | Result |
+|-------|----------|--------|
+| `eu-primary` | 0 | Receives all traffic under normal conditions. |
+| `us-backup` | 10 | Only receives traffic when every origin in `eu-primary` fails. |
+
+To distribute traffic *across* both groups instead, give them the same priority; the group balancing method then decides between them for every request.
+
+## Weights
+
+Weights (1 to 255) only apply with the Weighted Random method and are relative: an origin with weight 200 receives twice the traffic of an origin with weight 100. There is no need for weights to add up to any particular total.
+
+## Per-request overrides with Edge Rules
+
+Two [Edge Rule](/cdn/edge-rules/index) actions let you override routing for matching requests:
+
+- **Use Load Balancer** routes matching requests through a specific Load Balancer, and can prefer or force a specific origin group or origin. Preferred targets are tried first with normal failover behind them; forced targets disable failover entirely.
+- **Force Sticky Session Mode** overrides the Load Balancer's [sticky session](/cdn/load-balancer/sticky-sessions) setting for matching requests.
+
+## Distribution accuracy
+
+Balancing state (round robin position, latency measurements, connection counts) is maintained independently by each edge server. Across the whole network the configured distribution holds statistically, but a single client will not observe a perfect 1-2-3 rotation, and very low-traffic zones may see uneven short-term distribution.
\ No newline at end of file
diff --git a/cdn/load-balancer/statistics.mdx b/cdn/load-balancer/statistics.mdx
new file mode 100644
index 00000000..3b51a88d
--- /dev/null
+++ b/cdn/load-balancer/statistics.mdx
@@ -0,0 +1,41 @@
+---
+title: Statistics
+description: Monitor per-origin traffic, latency, failures, and failover behavior for your Load Balancers.
+---
+
+Every Load Balancer records detailed statistics about the traffic it routes, broken down per origin and per origin group. Use them to verify your traffic distribution, spot a slow or failing origin, and understand how often failover happens.
+
+Statistics are available in the dashboard and through the API. See the [API reference](/api-reference/core) for the endpoint details.
+
+## Summary metrics
+
+| Metric | Description |
+|--------|-------------|
+| Total requests | Requests handled by the Load Balancer. Requests served from the CDN cache are not included. |
+| Total traffic | Bytes served from your origins through the Load Balancer. |
+| Average origin RTT | Representative origin response time (time to first byte) across all origins. |
+| Requests with failover | How many requests needed more than one origin before succeeding, and the average number of extra origins tried. |
+| All origins exhausted | Requests that failed on every origin and returned `502` to the client. |
+| Sticky session hits | Requests routed by an existing [sticky session](/cdn/load-balancer/sticky-sessions) instead of the balancing method. |
+| Requests by method | Request counts per HTTP method. |
+
+## Per-origin time series
+
+- **Requests by origin and by origin group**: how traffic was distributed. Use this to confirm weights and priorities behave as intended.
+- **Traffic by origin**: bytes served per origin.
+- **Origin latency**: response time per origin, as mean and 50th, 90th, 95th, and 99th percentiles.
+- **Origin failures**: failed attempts per origin, broken down by status code. Connection-level failures (timeouts, refused connections) are reported as `502` or `504`.
+
+## Interpreting the numbers
+
+**Requests are attributed to the origin that produced the served response.** Attempts that failed and were failed over to another origin are not counted as requests for the failing origin; they appear in that origin's failure counts instead. If you compare bunny statistics with your own origin access logs, the difference corresponds to the attempts that failed over.
+
+**Failures count attempts, not client errors.** A single client request that fails over across three origins records a failure on the first two and a request on the third, while the client sees one successful response.
+
+## Time ranges
+
+Statistics can be grouped daily or hourly. A single query can cover up to 90 days. The account-level overview shows month-to-date totals for every Load Balancer, including how many Pull Zones each one is attached to.
+
+## Billing usage
+
+The usage endpoint reports month-to-date billable requests against the included allowance for each Load Balancer, along with when the allowance resets. See [Pricing](/cdn/load-balancer/pricing) for how requests are billed.
diff --git a/cdn/load-balancer/sticky-sessions.mdx b/cdn/load-balancer/sticky-sessions.mdx
new file mode 100644
index 00000000..1fe04e1e
--- /dev/null
+++ b/cdn/load-balancer/sticky-sessions.mdx
@@ -0,0 +1,33 @@
+---
+title: Sticky Sessions
+description: Keep returning visitors pinned to the same origin using cookies.
+---
+
+Sticky sessions route repeat requests from the same visitor to the same origin. Use them when your application keeps per-user state on the origin server, such as login sessions or shopping carts that are not shared between backends.
+
+Sticky sessions are configured on the Load Balancer and are disabled by default. Sessions are tracked with a client cookie.
+
+## How it works
+
+When cookie stickiness is enabled, the first response to a visitor sets an encrypted cookie named `bunny_lb_{id}` that records which origin served them. Subsequent requests carrying a valid cookie are routed to that origin, bypassing the balancing method.
+
+The cookie is a session cookie (it expires when the browser closes) and is set with `HttpOnly` and `SameSite=Lax`. The `Secure` flag is added when the request arrives over HTTPS. Its content is encrypted, so it cannot be read or forged by the client.
+
+## When a session breaks
+
+A sticky session is an optimization, never a guarantee. The visitor is re-balanced to a new origin (and receives a fresh cookie) whenever:
+
+- The pinned origin is unhealthy, disabled, or temporarily failing. Health always wins over stickiness.
+- The Load Balancer configuration changes. Edits to the Load Balancer, its groups, or its origins can invalidate active sessions.
+- The visitor's IP address changes. Sessions are bound to the client's network address, which limits cookie theft but means clients that switch networks are re-balanced.
+
+Design your application to tolerate a visitor occasionally landing on a different origin, for example by using a shared session store.
+
+## Interactions
+
+
+ Sticky sessions are automatically disabled on Pull Zones that have [Request Coalescing](/cdn/request-coalescing) enabled. Coalescing shares one origin fetch between many concurrent clients, which is incompatible with per-visitor origin pinning.
+
+
+- Stickiness only applies to requests that reach the origin. Cached responses are served from the edge regardless of the cookie.
+- The [Force Sticky Session Mode Edge Rule](/cdn/load-balancer/routing#per-request-overrides-with-edge-rules) can enable or disable stickiness for specific requests.
diff --git a/cdn/logging/origin-errors.mdx b/cdn/logging/origin-errors.mdx
index 7fe5bf18..2ab9808c 100644
--- a/cdn/logging/origin-errors.mdx
+++ b/cdn/logging/origin-errors.mdx
@@ -30,6 +30,9 @@ Available for all users at no extra cost.
- network_io_error
- dns_lookup
- notfound_localdb
+- ssl_error
+- loadbalanced_origin_failure
+- origin_url_malformed
- error
## Dashboard
diff --git a/docs.json b/docs.json
index 40a1e54c..47dd60ad 100644
--- a/docs.json
+++ b/docs.json
@@ -174,6 +174,18 @@
"cdn/edge-rules/pattern-matching"
]
},
+ {
+ "group": "Load Balancer",
+ "pages": [
+ "cdn/load-balancer/index",
+ "cdn/load-balancer/origins",
+ "cdn/load-balancer/routing",
+ "cdn/load-balancer/sticky-sessions",
+ "cdn/load-balancer/health-and-failover",
+ "cdn/load-balancer/statistics",
+ "cdn/load-balancer/pricing"
+ ]
+ },
{
"group": "Performance",
"pages": [