---
title: "Step 7: Verify the installation"
description: Run five checks that prove sign-in, the API gateway, and the web UIs of OpenLM Platform work before users sign in.
product: OpenLM Platform
---

Run these five checks to prove that the parts users depend on work. They take 2 minutes. Load the variables from `openlm-install.env`, the file you created from the [installation worksheet](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/worksheet), and set the address:

```bash
source ./openlm-install.env
H="https://$DOMAIN"
```

Run each check and compare its output with the **Expected** column:

| # | Check | Command | Expected |
|---|---|---|---|
| 1 | The home page loads | `curl -s -o /dev/null -w '%{http_code}\n' $H/` | `200` |
| 2 | Sign-in is up | `curl -s -o /dev/null -w '%{http_code}\n' $H/identity/.well-known/openid-configuration` | `200` |
| 3 | The API refuses anonymous calls | `curl -s -o /dev/null -w '%{http_code}\n' $H/api/licensemanager/bff/user` | `401` |
| 4 | Agents can register | `curl -s -o /dev/null -w '%{http_code}\n' $H/api/agents-hub/announce` | `200` |
| 5 | Nothing is failing | `kubectl -n $NS get pods --no-headers \| grep -vE "Running\|Completed"` | no output |

Run the `curl` commands **without** `-k`. If they work only with `-k`, your certificate isn't trusted, and users' browsers and the OpenLM Platform services reject it too. See [TLS certificates](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/concepts/tls-certificates).

## Fix a failed check

If a check gives a different answer, find it in the following table:

| Check | You got | Meaning and fix |
|---|---|---|
| 1 | `000` or a timeout | DNS or ingress isn't reaching the cluster. Repeat [step 1.4](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-1-prepare-cluster#14-create-the-dns-name). |
| 1 | `404` | The ingress controller answers but has no rule for `$DOMAIN`. Check `global.masterIngress.hostname` and `ingressClassName` in your values. |
| 2 | `404`, `502` or `503` | The identity service isn't ready yet, or is failing. Read its log: `kubectl -n $NS logs deploy/openlm-identity` |
| 3 | `404` | The services started before identity was healthy and fell back to a mode without security. Restart them once identity is healthy: `kubectl -n $NS rollout restart deployment` |
| 3 | `502` or `503` | The API gateway isn't running or isn't reachable. Repeat the check in [step 5](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-5-gateway). |
| 3 | `503` with `IdentityUnavailable` in the body | Services can't reach `https://$DOMAIN/identity` from inside the cluster. See [Networking](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/concepts/networking#reaching-the-platform-address-from-inside-the-cluster) |

:::tip[Check]
All five checks give the expected answer.
:::

:::note[If services reject tokens after a first installation]
On a first installation, services that start after the identity service has finished its setup sometimes keep rejecting tokens. Restart identity once, after all pods are running:

```bash
kubectl -n "$NS" rollout restart deployment/openlm-identity
kubectl -n "$NS" rollout status deployment/openlm-identity
```
:::