After a Load Balancer is created, it appears on the **Load Balancers** page in the [Gcore Customer Portal](https://portal.gcore.com). Navigate to **Cloud** > **Networking** > **Load Balancers** to open the page.
The page lists each Load Balancer with the following columns:
* **Name**: display name and brief configuration summary * **IP Address**: address assigned to the Load Balancer * **Listeners**: number of configured listening ports * **Region**: data center location * **Tags**: metadata labels assigned to the Load Balancer * **Created**: deployment date and time * **Operating status**, **Provisioning status**: see [Statuses](#statuses-of-load-balancers-and-their-components)A Load Balancer and its components (listener, pool, and pool member) each carry two types of statuses.
**Operating status** — the current observed state:
| Status | Meaning | | --------------- | ----------------------------------------------------------------------- | | **Online** | Operating normally; all pool members are healthy | | **Draining** | Pool members are no longer accepting new connections | | **Offline** | Load Balancer is not accepting new connections | | **Degraded** | One or more pool members are in an error state | | **Error** | Load Balancer has failed, or all pool members are failing health checks | | **No\_monitor** | No health monitor is configured; status unknown |**Provisioning status** — the lifecycle stage:
| Status | Meaning | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Active** | Successfully created | | **Deleted** | Successfully deleted | | **Updating** | Currently being updated | | **Deleting** | Currently being deleted | | **Error** | Creation failed. If an error occurs during update or deletion, [initiate a failover](#failover). Load Balancers that fail to be created are automatically deleted. |Adding or removing listeners and pools, and modifying listener properties, do not affect active connections. Two operations terminate all existing connections: changing the flavor and initiating a failover.
| Operation | Terminates connections | | ----------------------------- | ---------------------- | | Adding a listener | No | | Modifying listener properties | No | | Adding a pool | No | | Removing a listener | No | | Changing flavor | Yes | | Initiating failover | Yes |Schedule flavor changes and failover operations during a maintenance window to minimize disruption.
## Load balancer settingsClick a Load Balancer's name on the list page to open its detail view. The top section always shows the routing scheme, VIP address, Floating IP (if configured), and current statuses. The lower section is organized into tabs.
Top-section fields:
* **Routing scheme**: visualization of traffic flow through the Load Balancer — ingress and egress paths * **Type**: network distribution type — external (public) or private * **VIPs**: virtual IP address of the Load Balancer * **Floating IP**: Floating IP assigned during creation, if configured * **Operating status**, **Provisioning status**: see [Statuses](#statuses-of-load-balancers-and-their-components) ### FlavorThe **Flavor** tab shows the load balancer's current configuration and real-time resource metrics.
* **Flavor**: configuration name defining the vCPU and RAM allocation
* **vCPU**: number of virtual CPU cores
* **RAM**: RAM in Gibibytes (GiB)
* **ID**: unique Load Balancer identifier
* **Active connections**: ongoing connections currently handled
* **Bytes in**: total data received
* **Bytes out**: total data sent
* **Request errors**: errors encountered during request handling
* **Total connections**: cumulative connections since creation
### Monitoring
The **Monitoring** tab shows performance metrics for assessing health and capacity. Data is available in hourly views (1, 6, or 24 hours) and weekly views (1 or 2 weeks). The auto-refresh interval can be set to 1, 5, 15, or 30 minutes, or one hour.
* **CPU Utilization, %**: percentage of CPU currently in use. High values indicate the Load Balancer is nearing capacity, typically from high connection volume or traffic.
* **RAM Utilization, %**: percentage of memory in use. Terminated HTTPS traffic consumes more RAM than other traffic types.
* **Network traffic**: ingress and egress traffic rate in kbit/s.
* **Network packets**: packet rate (PPS) for ingress and egress.
### Listeners
A listener is a process that monitors a configured protocol and port for incoming connections and forwards traffic to an assigned pool.
Each listener shows:
* **Name**: listener name * **Protocol**: network protocol handled by the listener * **Port**: port monitored for incoming connections * **Pools**: number of attached backend pools * **Operating status**: current operational state * **Provisioning status**: configuration lifecycle stateA pool is the set of Virtual Machines or Bare Metal servers to which a listener forwards traffic.
Each pool shows:
* **Name**: pool name * **Algorithm**: traffic distribution method — see [pool settings](/cloud/networking/create-and-configure-a-load-balancer#pool) for available options * **Instance count**: number of backend instances * **Health Check**: health monitoring method * **Operating status**: current operational state * **Provisioning status**: configuration lifecycle stateInstances in each pool:
* **State**: whether the instance is enabled or disabled within the pool
* **Address**: IP address the Load Balancer uses to forward traffic to this instance
* **Port**: port the instance listens on
* **Operating status**: current operational state
* **Provisioning status**: configuration lifecycle state
Health check configuration:
* **State**: whether health monitoring is enabled for the pool
* **Type**: health check method (TCP, HTTP, HTTPS, PING, TLS-HELLO, UDP-CONNECT)
* **Operating status**: current operational state of the health monitor
* **Provisioning status**: configuration lifecycle state
#### L7 policies
An L7 policy specifies how to route incoming traffic at the application layer (Layer 7 of the [OSI model](https://en.wikipedia.org/wiki/OSI_model)).
#### Listener statistics
* **Name**: listener name
* **Active connections**: ongoing connections to the listener
* **Bytes in**: total data received
* **Bytes out**: total data sent
* **Request errors**: total request errors
* **Total connections**: cumulative connections since listener creation
### Configuration
The **Configuration** tab sets the Load Balancer flavor. Select a different flavor to resize the Load Balancer.
### Logging
The **Logging** tab records detailed traffic information for debugging, monitoring, and analysis. The [Logging for Load Balancers](/cloud/networking/load-balancers/logging-for-load-balancers) article covers all available settings.
### Tags
The **Tags** tab displays and manages metadata assigned to a Load Balancer. Tags group related resources — for example, Load Balancers belonging to the same service (authentication, shop, cart) can share a tag to make them easy to identify and manage together.
### Advanced DDoS Protection
The **Advanced DDoS Protection** tab configures DDoS mitigation policies for the Load Balancer.
## LimitsThe following limits apply per Load Balancer:
| Component | Limit | | ------------------- | ------------------------- | | Load Balancers | Managed by Quotas | | Listeners | 50 (excluding Prometheus) | | Prometheus Listener | 1 | | Pools | 50 | | Members | 2500 |Use failover to redirect traffic from a degraded or failed Load Balancer to a standby instance. The switchover completes in a few minutes.
4. (Optional) To force failover regardless of provisioning status, enable **Ignore Load Balancer provisioning status**.
5. Click **Initiate Failover**.
The failover takes a few minutes. The provisioning status changes to **Updating** during this time.
## Rename a load balancer 1. Navigate to **Cloud** > **Networking** > **Load Balancers**. 2. Click the three-dot icon next to the Load Balancer to rename. 3. Select **Rename**.
4. Enter a new name and click **Save**.
## Edit tags
1. Navigate to **Cloud** > **Networking** > **Load Balancers**.
2. Click the Load Balancer name to open its settings.
3. Navigate to the **Tags** tab.
4. Update tags and click **Save**.
## Delete a load balancer
1. Navigate to **Cloud** > **Networking** > **Load Balancers**.
2. Click the three-dot icon next to the Load Balancer to delete.
3. Select **Delete**.
4. Click **Delete** to confirm.
After a load balancer is deployed, you can inspect its configuration, update metadata, initiate a failover, or remove it. The examples below cover each of these day-two operations.
Open a bash terminal and set these as environment variables before running the examples:
```bash theme={null} export GCORE_API_KEY="{YOUR_API_KEY}" export GCORE_CLOUD_PROJECT_ID="{YOUR_PROJECT_ID}" export GCORE_CLOUD_REGION_ID="{YOUR_REGION_ID}" export LB_ID="{YOUR_LOAD_BALANCER_ID}" ``` ## List load balancersListing returns all load balancers in the region with their operating status, provisioning status, and VIP address.
Fetching a single load balancer returns the full configuration including flavor, VRRP IPs, listener list, tags, and logging settings.
A single PATCH request accepts any combination of `name` and `tags` — omitted fields remain unchanged. The operation returns a task ID and completes in under 30 seconds.
| Parameter | Required | Description | | --------- | -------- | ---------------------------------------------------------------------------- | | `name` | No | New name for the load balancer | | `tags` | No | Key-value pairs to add or update tags; set a value to `null` to remove a tag |GET /cloud/v1/tasks/{task_id} every 5 seconds until `state` is `FINISHED`.
Failover redirects traffic to a standby load balancer instance when the active one fails or degrades. All active connections are terminated during the switchover, which takes 1-2 minutes.
GET /cloud/v1/tasks/{task_id} every 5 seconds until `state` is `FINISHED`. Failover takes 1-2 minutes.
Deleting a load balancer removes it and its configuration permanently. The operation is asynchronous and takes about 30 seconds.
GET /cloud/v1/tasks/{task_id} every 5 seconds until `state` is `FINISHED`.
Query existing load balancers or update a managed one. The [provider v2](/developer-tools/terraform/overview) exposes both a resource and a data source for [`gcore_cloud_load_balancer`](https://registry.terraform.io/providers/G-Core/gcore/latest/docs/resources/cloud_load_balancer).
Use the `gcore_cloud_load_balancers` data source to retrieve all balancers in a region:
```hcl theme={null} data "gcore_cloud_load_balancers" "all" { project_id = var.project_id region_id = var.region_id } output "load_balancers" { value = [for lb in data.gcore_cloud_load_balancers.all.items : { id = lb.id name = lb.name vip_address = lb.vip_address operating_status = lb.operating_status }] } ```Run `terraform plan` to display the list.
## Get load balancer detailsUse the `gcore_cloud_load_balancer` data source to read the full configuration of a balancer by its ID:
```hcl theme={null} variable "lb_id" { type = string } data "gcore_cloud_load_balancer" "existing" { project_id = var.project_id region_id = var.region_id load_balancer_id = var.lb_id } output "lb_details" { value = { name = data.gcore_cloud_load_balancer.existing.name vip_address = data.gcore_cloud_load_balancer.existing.vip_address operating_status = data.gcore_cloud_load_balancer.existing.operating_status provisioning_status = data.gcore_cloud_load_balancer.existing.provisioning_status } } ``` ## Modify a managed load balancerTo rename, retag, or resize a load balancer that Terraform manages, update the relevant attributes and run `terraform apply`:
```hcl theme={null} resource "gcore_cloud_load_balancer" "example" { project_id = var.project_id region_id = var.region_id name = "my-lb-production" # rename flavor = "lb1-2-4" # resize tags = { env = "production" owner = "platform-team" } } ```Rename and tag updates complete in under 30 seconds and do not interrupt traffic.
Failover is an operational trigger. Use the [Customer Portal](#portal) or [REST API](#api) tab to initiate it.
## Delete a load balancerRemove the load balancer resource block and all associated listener and pool blocks — Terraform deletes them in the correct dependency order on the next `terraform apply`.
```hcl theme={null} # Remove or comment out all blocks: # resource "gcore_cloud_load_balancer_pool" "backend" { ... } # resource "gcore_cloud_load_balancer_listener" "http" { ... } # resource "gcore_cloud_load_balancer" "example" { ... } ``` ```bash theme={null} terraform apply ```