> ## Documentation Index
> Fetch the complete documentation index at: https://arize-ax.mintlify.site/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Validate your deployment

> Check pod health, ingress, and connectivity after installing Arize AX.

## Pod status

List workloads in the `arize` namespace:

```bash theme={null}
kubectl get pods -n arize
kubectl get pods -n arize-operator
```

You do **not** need every pod name memorized upfront. Treat this as a **spot check**: anything not `Running` or `Completed` deserves a `describe` and `logs` pass. For a deeper workload inventory, use the operational guide in the offline **`docs/`** bundle from your distribution archive.

### Namespaces and workloads to expect

Workloads are split between **`arize`** (platform services) and **`arize-operator`** (operator). Exact **Deployment** and **StatefulSet** names change by AX release—always compare `kubectl` output to the operational guide for **your** tarball version.

Typical checks:

```bash theme={null}
kubectl get deployments,statefulsets -n arize
kubectl get deployments -n arize-operator
```

Non-exhaustive examples you often see when healthy (names vary by release): operator and reconciliation components in **`arize-operator`**; app API/UI path through **`internalendpoints-app`** (a `Service` backed by one or more pods); data-plane pieces such as **receiver**, **ArizeDB / Druid router**, and **Gazette**-related workloads in **`arize`**. If several core Deployments are not **Available**, open the release's offline **`docs/`** and follow troubleshooting before sending production traffic.

Investigate any pod not `Running` or `Completed`:

```bash theme={null}
kubectl -n arize describe pod <pod-name>
kubectl -n arize logs <pod-name>
```

## Ingress and DNS

If you configured ingress, confirm the ingress object and endpoints:

```bash theme={null}
kubectl -n arize get ingress
kubectl -n arize describe ingress <ingress-name>
```

Confirm DNS resolves to your load balancer or ingress IP:

```bash theme={null}
nslookup arize-app.<your-domain>
```

## Log in to the UI

Open the URL you set in `appBaseUrl` in a browser. Sign in with the admin path your organization configured (or the bootstrap flow Arize AI documented for your release). Complete TLS issuance can take time on first setup — see [Configuring ingress endpoints](/ax/selfhosting/installation/ingress/configuring-endpoints) or your platform's load balancer page ([GCP](/ax/selfhosting/installation/gcp/ingress-gcp-load-balancer), [Azure](/ax/selfhosting/installation/azure/ingress-azure-load-balancer)).

Confirm the app loads and basic navigation works **before** you send production traffic or SDK data.

## Send test data

After the UI loads successfully, send traces or model data using the [SDK usage](/ax/selfhosting/guides/sdk-usage) guide for your SDK version. Use the same base URLs your ingress exposes for OTLP and HTTP APIs.

For deeper operational checks, use the operational guide in the offline **`docs/`** bundle from your distribution archive (open `docs/index.html` locally).