> ## 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.

# Demo Verifying the PaymentUI

> Verifying Payment UI reachability and diagnosing Kubernetes service failures causing frontend 503 errors by inspecting pods services endpoints readiness probes and logs in the payment namespace

Hello and welcome back.

Earlier we began debugging a Kubernetes incident with Alina where the payment gateway was failing. In this lesson we'll verify whether the Payment UI is reachable and confirm the user-facing error so we can trace the failure to the underlying infrastructure.

First, ensure you can talk to the cluster. A quick way to sanity-check cluster access is:

```bash theme={null}
# If using k3s:
k3s kubectl get nodes

# Or using the cluster's kubectl:
kubectl get nodes
```

What error do users see? The incident report says the payment gateway is down — let’s validate that from the frontend.

* In the KodeKloud lab UI, open the playground container menu (three dots) → View Port → open the frontend port.
* I recommend opening the resulting URL in an incognito/private window to avoid cached sessions or credentials affecting the test.
* When the page loads, look for an incident banner and the service health box for the Payment API.

You should see a banner confirming an incident has been detected, which tells us the frontend static hosting is reachable. The service health widget, however, should show the Payment API as down — explaining the failed payments.

![A dark-themed checkout screenshot for "AirPay" showing an order summary and card payment form on the right. A red incident banner and a service health box indicate the Payment API is down and the payment processing service is unreachable.](https://mintcdn.com/kodekloud-c4ac6d9a/rjGeTDj8cr6D5YbW/images/Building-Kubernetes-FinOps-AI-Agent/The-Problem-Statement/Demo-Verifying-the-PaymentUI/airpay-checkout-payment-api-down.jpg?fit=max\&auto=format\&n=rjGeTDj8cr6D5YbW\&q=85\&s=57f71c33405197e441adad5530ec3116)

Reproduce the failure by entering dummy card details and clicking Pay Securely. The browser console or network tab will show the frontend failing to POST to the payment API, returning a 503:

```text theme={null}
Error: fetch POST /api/charges 503 Service Unavailable - upstream: payment-gateway-api:8080 - No healthy upstream / connection refused
```

This message means the frontend could not reach any healthy backend for the `payment-gateway-api` service (connection refused / no healthy upstream). That points to an infrastructure-level issue: the frontend cannot connect to healthy backend endpoints.

You are acting as an SRE/DevOps engineer during this lesson. Focus on identifying and fixing the infrastructure/service issue (pods, services, endpoints, readiness/liveness), rather than changing application code.

Quick checklist — what to inspect next:

| Resource Type | Why check it | Example command |
| - | - | - |
| Pods | Are payment pods running / crashlooping / failing readiness? | `kubectl get pods -n payment` |
| Services | Is the Service targeting the right selector / port? | `kubectl get svc -n payment` |
| Endpoints | Does the Service have endpoints (IP:port) backing it? | `kubectl get endpoints -n payment` |
| Pod details | Describe pod to see events, readiness/liveness failures | `kubectl describe pod <pod-name> -n payment` |
| Logs | Check container logs for startup or runtime errors | `kubectl logs <pod-name> -n payment` |
| Deployment/ReplicaSet | Are replicas scheduled and available? | `kubectl get deploy,rs -n payment` |
| Network (optional) | Check network policies or DNS issues | `kubectl exec -it <pod> -n payment -- curl -sv payment-gateway-api:8080` |

A typical workflow:

1. `kubectl get pods -n payment` — note pod status (Pending, CrashLoopBackOff, Running).
2. If pods are not Ready or are CrashLooping, `kubectl describe pod <pod> -n payment` and `kubectl logs <pod> -n payment` to find errors.
3. `kubectl get svc -n payment` and `kubectl get endpoints -n payment` — confirm the service has endpoint IPs and correct ports.
4. If Service has no endpoints, check pod labels and Service selectors or readiness probes that may be preventing endpoints from being considered healthy.
5. Inspect readiness/liveness probes in the Deployment spec and adjust if misconfigured.

Next step: explore the `payment` namespace (pods, services, endpoints) and identify any misconfiguration, failing pods, or missing endpoints that cause the 503. Resolve the root cause (for example, fix readiness probe, scale pods, correct service selector) and then re-check the frontend to confirm successful payments.

Links and references

* [Kubernetes: What is Kubernetes?](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
* [kubectl reference](https://kubernetes.io/docs/reference/kubectl/overview/)
* [Diagnosing pod startup problems](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/)

That’s it for this lesson — proceed to inspect the payment namespace resources and determine where the failure originates.

> **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/5d434b76-bd5d-4526-b9c6-4a994c195994/lesson/3f1b6b9b-2ef2-4e87-a8be-bf8f35734867)**

> **[Practice Lab](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/5d434b76-bd5d-4526-b9c6-4a994c195994/lesson/c1bf63ed-3d33-43bc-bb20-7130e4478088)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.