---
name: openshift-ts-ingress-erriodeg
title: 'Ingress error: ERRIODEG'
description: Learn how to resolve `ERRIODEG` errors when the Ingress Operator is in a degraded state.
last-updated: 2026-08-14
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/openshift?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Ingress error: ERRIODEG
{: #ts-ingress-erriodeg}
{: troubleshoot}
{: support}



[Virtual Private Cloud]{: tag-vpc} [Classic infrastructure]{: tag-classic-inf} [Satellite]{: tag-satellite}

Learn how to resolve `ERRIODEG` errors when the Ingress Operator is in a degraded state.
{: shortdesc}

You can use the `ibmcloud oc ingress status-report ignored-errors add` command to add an error to the ignored-errors list. Ignored errors still appear in the output of the `ibmcloud oc ingress status-report get` command, but are ignored when calculating the overall Ingress Status.
{: tip}

When you check the status of your cluster's Ingress components by running the `ibmcloud oc ingress status-report get` command, you see an error similar to the following.
{: tsSymptoms}

```sh
The Ingress Operator is in a degraded state (ERRIODEG).
```
{: screen}

The Ingress Operator checks the health of the Ingress Controllers and enters a degraded state when the checks fail.
{: tsCauses}


Verify that your nodes are not overloaded. Overloaded nodes can cause Ingress Operator health checks to fail.
{: tsResolve}

To check whether you have adequate CPU and memory headroom, run the following command.
```sh
kubectl top nodes
```
{: pre}


Get the details of the `ingress` ClusterOperator and complete the steps based on the error message.

Check the status of the `ingress` ClusterOperator. If you see `False` in the `DEGRADED` column, wait 10 to 15 minutes to see if the Ingress Status warning disappears. If not, proceed with the troubleshooting steps based on the message in the `MESSAGE` column.
```sh
oc get clusteroperator ingress
```
{: pre}


## One or more status conditions indicate unavailable: `DeploymentAvailable=False`
{: #ts-ingress-erriodeg-da-false}

1. Ensure that your cluster has at least two workers. For more information, see [Adding worker nodes to Classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-add-workers-classic&format=markdown) or [Adding worker nodes to VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-add-workers-vpc&format=markdown).
1. Ensure that your cluster workers are healthy, otherwise Ingress Controller pods cannot be scheduled. For more information, see [Worker node states](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-reference&format=markdown).

## One or more status conditions indicate unavailable: `LoadBalancerReady=False`
{: #ts-ingress-erriodeg-lbr-false}

1. **VPC only**: Ensure that you did not reach your LBaaS instance quota. For more information, see [Quotas and service limits](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas&format=markdown#alb-quotas) and the `ibmcloud is load-balancers` [command](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&format=markdown#lb-anchor).
1. Ensure that your cluster masters are healthy. For more information, see [Reviewing master health](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_master&format=markdown#review-master-health).
1. Refresh your cluster masters by running the `ibmcloud oc cluster master refresh` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#cluster-master-refresh-cli).

## One or more other status conditions indicate a degraded state: `CanaryChecksSucceeding=False`
{: #ts-ingress-erriodeg-ccs-false}

1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster&format=markdown).

1. Ensure that the correct LoadBalancer service address is registered for your Ingress subdomain.
    1. Run the `ibmcloud oc cluster get` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#cluster-get-cli) to see your Ingress subdomain.
    1. Run the `ibmcloud oc nlb-dns get` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#nlb-dns-get-cli) to see the registered addresses.
    1. Run the `oc get services -n openshift-ingress` command to get the actual load balancer addresses.
    1. Compare the registered and actual addresses and update the subdomain if it differs.
        **VPC**: Run the `ibmcloud oc nlb-dns replace` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#nlb-dns-replace-cli) to replace the current address.
        **Classic**: Remove the currently registered addresses by running the `ibmcloud oc nlb-dns rm classic` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#nlb-dns-rm-classic-cli), then add the new addresses with the `ibmcloud oc nlb-dns add` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#nlb-dns-add-cli).
        **Satellite**: The actual addresses depend on your configuration: if you expose your worker nodes with an external load balancer, register the load balancer addresses, otherwise register the IP addresses assigned to the `router-external-default` service in the `openshift-ingress` namespace (use the `oc get services -n openshift-ingress router-external-default -o yaml` command to retrieve the addresses). Remove the currently registered addresses by running the `ibmcloud oc nlb-dns rm classic` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#nlb-dns-rm-classic-cli), then add the new addresses with the `ibmcloud oc nlb-dns add` [command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cli&format=markdown#nlb-dns-add-cli).

1. **VPC only**: canary health check traffic originates from one of the worker nodes of your cluster.
    - Health check traffic originates from one of the worker nodes of your cluster. In the case of clusters with public service endpoint, the traffic is directed to the public floating IP address of the VPC Load Balancer instance, therefore it is required to have a Public Gateway attached to all the worker subnets. In the case of clusters with only private service endpoints, the traffic is directed to the VPC subnet IP address of the VPC Load Balancer, therefore a Public Gateway is not required. For clusters with public service endpoint:
        1. Run the `ibmcloud is public-gateways` to see your public gateways.
        1. Run the `ibmcloud is subnets` to see your subnets.
        1. For every subnet run the `ibmcloud is subnet <subnet-id>` to check whenever it has a public gateway.
            1. If your subnet does not have a public gateway attached, you need to attach one. For more information, see [Creating public gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-create-public-gateways&interface=cli&format=markdown)
    - If your VPC Load Balancers are located on a subnet other than the worker nodes of your cluster, you must update the Security Group attached to the VPC Load Balancer subnet to allow incoming traffic from the worker subnets.
    - For more information, see [Creating a Red Hat OpenShift cluster in your Virtual Private Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_rh_tutorial&format=markdown), [Configuring VPC subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnets&format=markdown#vpc_basics_pgw) and [Creating and managing VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group-manage&format=markdown).

1. Ensure that no firewall rules block canary traffic or DNS traffic over UDP and TCP.
    **VPC**: canary traffic originates from one of the worker nodes, flows through a VPC Public Gateway and arrives to the public side of the VPC Load Balancer instance. Configure your VPC Security Groups to allow this communication. For more information, see [Understanding secure by default cluster VPC networking](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group-reference&format=markdown) and [Creating and managing VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group-manage&format=markdown).
    **Classic**: canary traffic originates from the public IP address of one of the worker nodes and arrives to the public IP address of your classic load balancers. Configure your network policies to allow this communication. For more information, see [Controlling traffic with network policies on classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies&format=markdown).

## Next steps
{: #ts-ingress-erriodeg-next}

1. Wait 30 minutes, then run the `oc get clusteroperator ingress` command and check the `MESSAGE` column again.
1. If you see a different error message repeat the troubleshooting steps.
1. If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/support?topic=support-using-avatar&format=markdown). In the case details, be sure to include any relevant log files, error messages, or command outputs.