> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/installation/rpm/rpm-single-node/start-and-verify.md).

# Start and verify

Confirm every tier is running and the console is reachable, so you can hand the deployment over with confidence.

## What this covers, and how long it takes

<table><thead><tr><th width="136.40000915527344"></th><th></th></tr></thead><tbody><tr><td><strong>You get</strong></td><td>A confirmed, documented check that every tier is running and the console is reachable</td></tr><tr><td><strong>Time</strong></td><td>15 minutes, after the platform has finished starting</td></tr><tr><td><strong>Hosts</strong></td><td>The host you installed on</td></tr><tr><td><strong>Downtime</strong></td><td>None</td></tr><tr><td><strong>Reversible</strong></td><td>Nothing is changed here — every command on this page reads</td></tr></tbody></table>

## Before you start

The installation has completed. **Allow up to 15 minutes for a cold start.** The application services wait for the infrastructure tier to be ready before they begin, so a check run immediately after the installer finishes will show services still coming up. That is normal.

Run these checks after every installation and keep the output — it is the record that the deployment was handed over healthy, and it is the first thing to compare against if behaviour changes later.

## Set these first

{% code overflow="wrap" %}

```bash
export OPENIAM_URL=<the address users will type — this host's name, or your load balancer's>
```

{% endcode %}

***

## Verify it

### 1. Ask the platform

{% code overflow="wrap" %}

```bash
openiam-cli status
```

{% endcode %}

**Expected:** every service listed, each reporting its application health. The checks that follow confirm the same picture component by component, and are what you keep with your build record.

### 2. The application services are running

{% code overflow="wrap" %}

```bash
pgrep -c -u openiam java
```

{% endcode %}

**Expected: 20 or more.**

To list them by name:

{% code overflow="wrap" %}

```bash
pgrep -a -u openiam java | grep -oE '[a-z0-9-]+\.(jar|war)' | sort
```

{% endcode %}

### 3. The infrastructure tier is ready

**Set the two credential variables first.** The cache and search checks read them from the secret store, which keeps the values off your command line:

{% code overflow="wrap" %}

```bash
V=/usr/local/openiam/utils/vault/vault.fetch.property.sh
export REDIS_PASSWORD="$(sudo $V vault.secret.redis.password)"
export OPENSEARCH_USER="$(sudo $V vault.secret.opensearch.username):$(sudo $V vault.secret.opensearch.password)"
```

{% endcode %}

`unset` them, or close the session, when you have finished — see [*Commands*](/installation/commands.md#reading-a-credential-from-the-secret-store).

Check each component directly:

{% code overflow="wrap" expandable="true" %}

```bash
# Secret store
curl -sk https://localhost:8200/v1/sys/seal-status | jq '.sealed'

# Graph storage
nodetool status

# Cache
redis-cli -a "$REDIS_PASSWORD" PING

# Message broker
rabbitmqctl status | head -5

# Search tier
curl -sk -u "$OPENSEARCH_USER" https://localhost:9200/_cluster/health | jq '.status'
```

{% endcode %}

**Expected:** `false` for the seal status, one node reported `UN` by `nodetool`, `PONG` from the cache, a running broker, and `green` or `yellow` for the search tier. **`yellow` is the correct result on a single node** — replica shards are unassigned because there is one node to hold them.

Read credentials from the secret store rather than typing them into a shell where you can avoid it; command lines are visible to other users on the host.

### 4. The service bus is answering

The enterprise service bus is the backbone every platform service talks through:

{% code overflow="wrap" %}

```bash
curl -s http://localhost:9080/openiam-esb/actuator/health | jq -r '.status'
```

{% endcode %}

**Expected: `UP`.**

### 5. The application health endpoints report UP

Each front-end service exposes a health endpoint. This is the same check the platform's readiness gate uses:

{% code overflow="wrap" %}

```bash
for p in 8082:webconsole 8086:openiam-ui-static 8081:idp \
         8083:selfservice 8084:selfservice-ext 8085:reportviewer; do
  port=${p%%:*}; app=${p##*:}
  printf '%-22s %s\n' "$app" \
    "$(curl -s -m 5 "http://localhost:$port/$app/actuator/health" | jq -r '.status // "starting"')"
done
```

{% endcode %}

**Expected: `UP` on all six.** During a cold start some will report `starting` until they finish — give the platform the full 15 minutes before investigating.

### 6. The console is reachable

Users reach the platform through the reverse proxy on port 80:

{% code overflow="wrap" %}

```bash
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/webconsole
curl -k -I -L http://127.0.0.1/idp/login
```

{% endcode %}

**Expected: `200` from the first, and `HTTP/1.1 200` from the second.** Together these exercise the proxy, the interface tier and the identity provider.

Then open the console from another machine to confirm it is reachable across the network:

{% code overflow="wrap" %}

```
http://$OPENIAM_URL/webconsole
```

{% endcode %}

### 7. Record the result

Keep the output of steps 1 to 6 with your build record. Handing over a deployment with its verification output attached saves the next person — often you, months later — from re-establishing what "healthy" looked like on day one.

***

## Next: first sign-in

The platform is running. **Go to** [***First sign-in***](/installation/rpm/rpm-single-node/first-sign-in.md) **next** — it sets the administrator password and tells OpenIAM the address it is published on, which the console uses to build links and route requests.

## If it goes wrong

Work from the bottom of the stack upwards; the application services depend on the tier beneath them.

| What you see                             | What it means                                                                               | What to do                                                                                                                                     |
| ---------------------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Process count is 0 or low                | The services are still waiting on the infrastructure tier, or one component is not ready    | Run step 2 and bring up whatever is not reporting healthy, then re-check                                                                       |
| Some health endpoints not yet `UP`       | A cold start in progress                                                                    | Allow the full 15 minutes                                                                                                                      |
| Search tier reports `yellow`             | Expected on a single node                                                                   | No action                                                                                                                                      |
| Console answers locally but not remotely | Port 80 is not open on the host firewall                                                    | `firewall-cmd --permanent --add-port=80/tcp && firewall-cmd --reload`. The installation adds this when you install the reverse proxy           |
| The console returns to the setup screen  | The first-time setup sequence has not been completed, or the cache refresh is still running | Complete [*First sign-in*](/installation/rpm/rpm-single-node/first-sign-in.md), then allow five minutes                                        |
| `Service Not Available` from the proxy   | The proxy's backend directives point somewhere the services are not                         | See [*Configure the reverse proxy*](/installation/rpm/rpm-single-node/configure-the-reverse-proxy.md)                                          |
| A single service is not running          | That service did not complete start-up                                                      | `systemctl restart openiam-<unit>`, then `openiam-cli log <name>` — the unit-to-log-name mapping is in [*Commands*](/installation/commands.md) |

[*Troubleshoot*](/installation/rpm/rpm-single-node/troubleshoot.md) covers these and the less common cases in more detail.

## What comes next

This page confirms the platform is running. Configuring it for your organisation — connecting managed systems, defining policy, synchronising users — is the [Administration Guide](/administration-guide/admin.md).

Cache, batch, pool and rate-limit properties are on [Configuration tuning reference](/installation/tuning.md). Sizing for your expected load is not documented yet — ask OpenIAM support.

## What this procedure does not cover

Configuring the platform. This page confirms the deployment runs; [*First sign-in*](/installation/rpm/rpm-single-node/first-sign-in.md) and [*Configure*](/installation/rpm/rpm-single-node/configure.md) come next. Ongoing health checks are [*Diagnostics*](/installation/diagnostics.md).

## Related

* [*Configure*](/installation/rpm/rpm-single-node/configure.md) — settings to review before the deployment is used
* [*Add a connector*](/installation/rpm/rpm-single-node/add-a-connector.md) — connect your first managed system
* [*Troubleshoot*](/installation/rpm/rpm-single-node/troubleshoot.md)
* [*Ports*](/installation/rpm/rpm-single-node/ports.md)

*Applies to OpenIAM 2026.8.1.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/installation/rpm/rpm-single-node/start-and-verify.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.