> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Status Fields and Conditions > Explains Gateway API status fields and conditions for diagnosing Kubernetes resources by interpreting type, status, reason, and message to troubleshoot configuration, attachments, and controller issues. This lesson explains the status fields exposed by the [Gateway API](https://gateway-api.sigs.k8s.io/) that help you verify a resource's state and troubleshoot attachment issues. Kubernetes CLI output is useful, but Gateway API status fields provide structured, controller-level details that make diagnosing configuration and runtime problems easier. A presentation slide titled "Status Fields" comparing two approaches: a left orange box for "Traditional Workflow" with bullets about CLI familiarity and standard outputs, and a right green box for "GateWay API Advantages" listing extra fields, easier troubleshooting, and verification of resource creation. The two columns are numbered 1 and 2 and styled with colored headers.

A presentation slide titled "Status Fields" comparing two approaches: a left orange box for "Traditional Workflow" with bullets about CLI familiarity and standard outputs, and a right green box for "GateWay API Advantages" listing extra fields, easier troubleshooting, and verification of resource creation. The two columns are numbered 1 and 2 and styled with colored headers.

Conditions Conditions are one of the most actionable pieces of information in Gateway API status. Every Gateway API resource includes a `conditions` array under `status`. Each element in this array reports a specific aspect of the resource's state and contains fields that help explain what's happening. Key fields inside each condition: | Field | Purpose | Example | | - | - | - | | `type` | Which aspect of the resource is being reported (stage or facet). | `Accepted` | | `status` | Whether that aspect is true, false, or unknown. | `True` | | `reason` | Short CamelCase token identifying why the status was set. | `InvalidParameters` | | `message` | Human-readable explanation with contextual details. | `"Accepted by gateway-controller"` | Conditions are most useful when combined with resource specs, Kubernetes events, and controller logs. Treat them as directional clues to guide further investigation rather than the single source of truth. Type The `type` field indicates the facet or step the condition describes. Knowing which types are present — and their `status` — narrows down where the controller is failing or succeeding. Common `type` values you’ll see: * `Accepted` — The controller validated the resource and accepted the configuration. * `Programmed` — Configuration is being (or has been) pushed from control plane to data plane. * `ResolvedRefs` — References to other Kubernetes objects (for example, `Secrets` or `Services`) were validated and resolved. Each `type` represents a stage or validation point; inspect the corresponding `status`, `reason`, and `message` to localize issues. A presentation slide titled "Conditions: The 'Type' Field" showing four condition fields (Type, Status, Reason, Message) with example condition types like "Accepted," "Programmed," and "ResolvedRefs" and brief descriptions beneath them.

A presentation slide titled "Conditions: The 'Type' Field" showing four condition fields (Type, Status, Reason, Message) with example condition types like "Accepted," "Programmed," and "ResolvedRefs" and brief descriptions beneath them.

Status The `status` subfield is one of `True`, `False`, or `Unknown`. It summarizes whether the condition passed, failed, or could not be determined. * `True` — The check passed (e.g., the controller accepted the configuration). * `False` — The check failed; further investigation is required (inspect `reason`, `message`, related resources, events, and controller logs). * `Unknown` — The controller could not determine the state (often transient or a control-plane communication problem). The image is a slide titled "Conditions: The 'Status' Field" showing four fields — Type, Status, Reason, and Message — with icons above and a breakdown of status values (True, False, Unknown) and brief explanations for each. It appears to be a diagram explaining possible condition outcomes and their meanings.

The image is a slide titled "Conditions: The 'Status' Field" showing four fields — Type, Status, Reason, and Message — with icons above and a breakdown of status values (True, False, Unknown) and brief explanations for each. It appears to be a diagram explaining possible condition outcomes and their meanings.

If you see `status: "False"` or `status: "Unknown"`, always check the `reason` and `message` first, then validate referenced Kubernetes objects (for example, `Secrets` and `Services`) and controller logs to identify the root cause. Reason The `reason` is a concise, machine-friendly token (typically CamelCase) that identifies why the controller set the `status` the way it did. Controllers and the Gateway API define common reason values; reading the reason points you to the exact validation or runtime check that failed. Common reasons: * `InvalidParameters` * `UnsupportedValue` * `InvalidListener` * `NoMatchingParent` Message The `message` field is human-readable and provides additional context beyond the `reason`. When you combine `type`, `status`, `reason`, and `message`, you get a clearer picture of the problem and hints about what to check next. Example success messages include `RouteAccepted` or `GatewayProgrammed`. Quick troubleshooting actions by `reason`: | Reason | Likely cause | Recommended checks | | - | - | - | | `InvalidParameters` | Spec fields contain invalid values | Validate resource spec against Gateway API docs and controller docs | | `UnsupportedValue` | Controller or dataplane doesn't support the requested feature | Check controller/version capability matrix and upgrade or change config | | `InvalidListener` | Listener config (e.g., TLS, ports) is incorrect | Inspect `listeners` in the Gateway spec and referenced `Secrets` | | `NoMatchingParent` | Route cannot find a parent Gateway or matching attachment | Confirm `parentRefs` and `Gateway` selectors/namespaces | How to view conditions Use `kubectl` to inspect a resource's status and its conditions. Example — view a Gateway in YAML form: ```bash theme={null} kubectl get gateway my-gateway -n my-namespace -o yaml ``` You will see a `status.conditions` list similar to this example: ```yaml theme={null} status: conditions: - type: Accepted status: "True" reason: RouteAccepted message: "Accepted by gateway-controller" - type: Programmed status: "True" reason: GatewayProgrammed message: "Configuration pushed to data plane" - type: ResolvedRefs status: "True" reason: ResolvedRefs message: "All references resolved successfully" ``` When a condition shows `status: "False"`, examine the `reason` and `message`, then check related objects such as `Secrets` and `Services`, controller logs, and Kubernetes events to identify and fix the underlying issue. Conclusion Gateway API conditions provide structured, actionable information that simplifies troubleshooting. Always interpret `type`, `status`, `reason`, and `message` together, and corroborate the condition details with events, controller logs, and the resource spec to resolve problems efficiently. Resources and references * [Gateway API documentation](https://gateway-api.sigs.k8s.io/) * [Kubernetes: kubectl overview](https://kubernetes.io/docs/reference/kubectl/overview/) * [Kubernetes: Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) * [Kubernetes: Services](https://kubernetes.io/docs/concepts/services-networking/service/) * [Kubernetes: Events](https://kubernetes.io/docs/concepts/cluster-administration/events/) I hope you found this lesson helpful. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.