> 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/administration-guide/operations/diagnose-a-failed-operation.md). # Diagnose a failed operation Start from one failed operation, walk it down through the layers that each keep their own record, and finish knowing which layer failed and who owns the fix. ## What this is, and when you need it OpenIAM work crosses ten layers between the browser and the managed system, and each one keeps its own record. "It didn't work" is never a single fact — it is a fact at one specific layer, and the skill is knowing which layer to open first. This page walks one failed operation down through those layers, then gives the evidence map you jump into once you know which layer to open. Not every layer is administrative. Where the answer lives in a service log, in the front-end web server's configuration or in the database itself, this page names the symptom you will notice and points at the [Installation Guide](/installation/installation.md) instead of reproducing a procedure you cannot run from the Webconsole. Everything here is read-only. The operations that change state are on their own pages: [Rebuild a search index](/administration-guide/operations/rebuild-a-search-index.md), [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md) and [Terminate a user's sessions](/administration-guide/security/session-management.md). ## At a glance | | | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | The layer that failed named, and the record that proves it — a `CONNECTOR_RESPONSE` child event, a queue with no consumer, a `TESTCONNECTION` result, or the managed system's own error. Nothing is changed; every step is a read | | **Where** | **User Admin → User Search** for the object, and the audit log at `/webconsole/viewAuditLog`. No shell access is needed | | **You need first** | The user or object the operation targeted, the managed system it should have reached, the minute it ran, and a Webconsole account that can open both of those screens | | **Takes** | 20–60 minutes, longer if you have to ask somebody else for a service log | | **Reversible** | Yes — nothing here writes, so there is nothing to undo; the risk starts the moment you skip to a rebuild before finishing the walk | ## Before you begin Have three things in front of you: the user, role or managed system the operation targeted; the time it ran, to the minute; and the name of the managed system that should have changed. You need all three to search the audit log and to ask someone else for a service log. Have a disposable test user to hand as well if you need to reproduce the failure rather than read it back. If somebody else fetches logs for you, [Which log answers which question](/administration-guide/operations/which-log-to-read.md) turns your symptom into the log name, the minute and the line to ask them to search for. ## Walk one failed operation through the layers The example is the common one and its shape generalises. A new hire was created in OpenIAM. The AD account never appeared. Nine steps, each naming the exact place to look — each one either ends the diagnosis or hands you the input for the next. {% stepper %} {% step %} ### Confirm the user object is right **User Admin → User Search**, open the user. Are the attributes that AD needs actually populated? If the user has no first name and your policy map maps `givenName` from it, the failure is here and no further layer will tell you so. Also confirm the user is entitled to the resource that owns the AD managed system — provisioning only targets resources the user is entitled to. {% endstep %} {% step %} ### Find the parent audit event `/webconsole/viewAuditLog`, filtered to the user and to `PROVISIONING_ADD` (or `PROVISIONING`, which is the umbrella action). Note the audit log id. If there is **no event at all**, provisioning was never requested: go back to entitlement and to whether the save actually reached the IDM. {% endstep %} {% step %} ### Read the provisioning stream on the event Open the event. OpenIAM records the ordered list of resources the operation intended to touch, both in the `provisionstream` index and as the `PROVISION_STREAM` audit attribute on the child audit log. If AD is not in that list, the operation never intended to provision it — the answer is entitlement or policy map, not the connector. {% endstep %} {% step %} ### Look for the connector response child event Search audit for `CONNECTOR_RESPONSE` (target `CONNECTOR`) in the same window, and match on the parent audit log id. That field is exactly how OpenIAM correlates a connector reply back to the provisioning operation that caused it, which is why the parent id is the only reliable way to pair them. If there is a connector response and it failed, you now have the managed system's own error and you are done diagnosing OpenIAM — go to the managed system. {% endstep %} {% step %} ### If there is no connector response: check the reply timeout The characteristic error text is `Response is not received from RabbitMQ during reply timeout`. The value in force in a shipped deployment is 120 seconds, not the 30 you will find in a properties file — see [the reply timeout](#the-broker-reply-timeout) below. A managed system that needs longer than the effective value produces exactly this symptom. Raising it is a deployment change, and it has to be raised on the IDM and synchronization services rather than on the ESB; see the [Installation Guide](/installation/installation.md). {% endstep %} {% step %} ### Check the connector is bound to its queue RabbitMQ management console, on the `openiam_connector` vhost: does the managed system's connector queue exist, and does it have a consumer? A queue with messages and no consumer is an unbound connector. Re-saving the connector at **Provisioning → Connectors** re-registers it, and OpenIAM's 60-second health sweep re-binds connector queues on its own — so wait one minute before doing anything more drastic. {% endstep %} {% step %} ### Check connector health, not connector liveness Managed system search, **Running connector status** column. That value comes from the `connectorreply` index, written by the 60-second `TESTCONNECTION` sweep. A connector process that is running but cannot reach AD shows here and nowhere else. {% endstep %} {% step %} ### Read the connector's own log This is the only layer that sees the target protocol error — a bind failure, a schema violation, a required attribute AD rejected — and none of it reaches an OpenIAM screen or the audit trail. The symptom you will have at this point is a connector that reports unhealthy, or a connector response carrying an error the managed system's own message explains better than OpenIAM can. Reaching that log is deployment-level work: see the [Installation Guide](/installation/installation.md), and give whoever fetches it the managed system name and the minute the operation ran. {% endstep %} {% step %} ### Confirm on the managed system, then confirm findability Look for the account in AD itself. If it is there and OpenIAM's screens disagree, you have an index problem, not a provisioning problem — run the [two-question test](/administration-guide/operations/rebuild-a-search-index.md#stale-index-versus-bad-data-the-two-question-test) and reindex `identity` or `orphan` as it indicates. {% endstep %} {% endstepper %} ## Verification A diagnosis is finished when you can name the layer that failed and point at the record that proves it, not when the symptom goes away. Three endings are normal: a `CONNECTOR_RESPONSE` child event carrying the target's own error; no provisioning event at all, which means the operation was never requested and the answer is entitlement or the policy map; or an operation that reached the queue and stopped there, which is the connector binding. There is nothing to roll back — every step above is a read. If this pattern recurs, the `FAILED_REQ_REPORT` batch task ("Failed provision requests report") exists for exactly this and **ships disabled** — see [Shipped batch tasks](/administration-guide/reference/shipped-batch-tasks.md). ## When it goes wrong | Symptom | Cause | Where to look / fix | | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The gateway log shows almost nothing | Container logging for the gateway is off until the deployment enables it | Deployment-level — [Installation Guide](/installation/installation.md) | | Raised a `logging.level.*` in the Webconsole, no change | Something below the property model already set the level for that service | [Where settings live](/administration-guide/start/where-settings-live.md), then the [Installation Guide](/installation/installation.md) | | `Response is not received from RabbitMQ during reply timeout` | Target slower than the effective reply timeout, which is 120 s in a shipped deployment | Time the gap between request and error to confirm which value is in force, then ask for it to be raised on the IDM and synchronization services | | Lengthened `org.openiam.rabbitmq.timeout` expecting a longer reply wait | That is the **connection** timeout, a different key | Use `org.openiam.mq.broker.reply.timeout` | | Connector queue has messages, no consumer | Connector unbound, usually because the IDM service started before the connector | Wait 60 s for the health sweep; otherwise re-save the connector | | The same bulk request is enqueued on `ProvisionBulkQueue` over and over | Another save of the same user was in progress, so each attempt requeued itself | Read the audit event for the underlying save failure; retries stop at `org.openiam.rabbitmq.message.max.retry.count` (`100`) with `Maximum retry count exceeded. Operation interrupted.` | | `PRECONDITION_FAILED - delivery acknowledgement on channel timed out. Timeout value used: 1800000 ms` | One request occupied a consumer for longer than the broker's own delivery-acknowledgement timeout, so the broker closed the channel. This is the consumer's working time, not the reply timeout | Reduce the work in a single request — for a directory feed, ask for the attributes you actually map rather than every attribute. The broker's timeout is deployment-level — [Installation Guide](/installation/installation.md) | | One connection in `rabbitmqctl list_connections` shows tens or hundreds of channels | Usually not a leak: every listener consumer holds its own channel, so a service with many listeners opens many channels | Compare the count with the ceiling in [Channel counts](#channel-counts) before restarting anything | | Health endpoint says `UP` while RabbitMQ or Redis is down | `management.health.rabbit.enabled` and `.redis.enabled` ship `false`, so neither contributes to the result | Read the health body — those components are absent from it — and check those layers directly | | CSV user import fails with 413 | The front-end web server's body-size ceiling, shipped 30 MB | Not an OpenIAM limit — [Installation Guide](/installation/installation.md) | | Restored a backup and every approval request is orphaned | Only the identity schema was restored; workflow state lives in another | All seven schemas have to be restored at the same point in time — [Installation Guide](/installation/installation.md) | | A connector fails and no OpenIAM screen says why | The target protocol error only reaches the connector's own log | Ask for that log with the managed system name and the minute — [Installation Guide](/installation/installation.md) | | Object correct on its own screen, invisible in search | Stale index | [Rebuild a search index](/administration-guide/operations/rebuild-a-search-index.md) | | Membership correct, effective access wrong | Stale authorization graph | [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md) | | Audit and log timestamps are exactly one hour earlier than wall-clock time | A whole-hour shift is timezone interpretation, never clock drift | [Timestamps off by a fixed offset](/administration-guide/operations/timestamps-off-by-a-fixed-offset.md) | ## The evidence map Once the walk points at a layer, this is what that layer keeps and where it is. | Layer | The real thing to inspect | Where | | ------------------------ | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Browser** | Response headers `x-openiam-login-uri` and `Content-Security-Policy`; the `OPENIAM_AUTH_TOKEN` cookie | Devtools network tab | | **Access Gateway** | The gateway's own error and access log, with the module's debug output | Deployment layer — [Installation Guide](/installation/installation.md) | | **Front-end web server** | Which service a path was routed to | Deployment layer — [Installation Guide](/installation/installation.md) | | **UI service** | The audit event the screen wrote, and the `idp` / `webconsole` / `selfservice` service log | `/webconsole/viewAuditLog`; the service log | | **ESB** | The ESB service log; on the gateway path, the calls the gateway makes to it | The service log; **About** at `/webconsole/about` for the build, under **ESB System Information** | | **RabbitMQ** | Queue depth, unacked messages, and whether the connector queue is bound at all | RabbitMQ management console, published as `/rabbitmq` through the gateway | | **Connector** | The connector reply document for that managed system and operation | Managed system dashboard; the `connectorreply` index | | **Managed system** | The account itself | The target directory or application | | **Database** | The row, in one of seven schemas | See [The seven database schemas](#the-seven-database-schemas) | | **Search index** | Whether the object is *findable* as opposed to *present* | 32 OpenSearch indexes — see [Search indexes and the authorization graph](/administration-guide/reference/search-indexes.md) | ### Browser Two response headers tell you the gateway is in the path and doing its job: `x-openiam-login-uri` and a `Content-Security-Policy` the gateway generates. A response served without the gateway has neither. The session cookie is `OPENIAM_AUTH_TOKEN` unless the content provider sets **Auth Cookie Name**, and when the `OPENIAM_CURRENT_USER_ID` cookie is present the current user id is appended to the cookie name — so a cookie whose name carries an id on the end is normal, not a corruption. Confirm the name your deployment uses on the content provider's own screen under **Access Control → Content Providers**. ### The Access Gateway The gateway keeps its own error log and access log, separate from every OpenIAM service log, and two things about them will mislead you if you do not know them first. In a container deployment the gateway writes nothing useful to the container log until the deployment turns that on, so an empty gateway log is a configuration state and not evidence that no request arrived. And the shipped starter configuration enables every debug and request-dump switch the module has, which puts passwords and session tokens into whatever collects your logs. You can tell which state you are in by opening the gateway log for one sign-in: request headers or a password field visible in it means the dumps are on, and the log is now a credential store. Both settings are deployment-level — see the [Installation Guide](/installation/installation.md). The directives themselves, and what each one prints, are in [Access Gateway reference](/administration-guide/gateway/access-gateway-reference.md#transport-worker-pool-and-debug). ### The front door and the service topology The UI services — `idp`, `webconsole`, `selfservice`, the report viewer, the static assets and the newer `-v2` screens — each answer on their own path behind a front-end web server, and the ESB is not behind it at all: the gateway reaches the ESB directly. So a path that returns a connection error while its neighbours work is a routing or port question at the deployment layer, and a large CSV import rejected with HTTP 413 hit that web server's body-size ceiling — shipped 30 MB — before OpenIAM saw it. Neither is an OpenIAM setting: see the [Installation Guide](/installation/installation.md). ### Service logs and log levels There are two layers to log configuration, and they are easy to confuse. **Spring log levels** are properties, and therefore follow the [four-layer model](/administration-guide/start/where-settings-live.md) like any other property: | Property | Shipped default | | ------------------------------------ | ------------------- | | `logging.level.org.springframework` | `INFO` | | `logging.level.org.hibernate` | `WARN` | | `logging.level.org.openiam` | `INFO` | | `logging.level.org.openiam.security` | `WARN` | | `logging.level.org.openiam.mq` | `INFO` | | `logging.path` | `${confpath}/logs/` | **A service-wide log level set by the deployment** is the second layer. It is not a property, it does not appear in the property screens, and the shipped starter values are deliberately verbose — trace on several backend services and debug on the gateway. This is the usual reason a level you raised or lowered in the Webconsole appears to have no effect: something below the property model already decided. [Where settings live](/administration-guide/start/where-settings-live.md) explains how to tell which layer won; the deployment side is in the [Installation Guide](/installation/installation.md). Which log belongs to which component, and how to retrieve it, also depends on how OpenIAM was deployed — pods on Kubernetes, or plain JVMs on an RPM host, each with a different set of service names and a different way of reaching a log. Retrieving a service log is a deployment-level task; the mapping for your installation is in the [Installation Guide](/installation/installation.md). ### The seven database schemas This is the single most consequential undocumented fact about OpenIAM operations: **it is not one database.** There are seven schemas, each named by its own property: | Schema | Property | Holds | | --------------- | ----------------------------------- | ----------------------------------------------------------------------------------------- | | `openiam` | `openiam.databaseSchema.name` | Everything identity: users, roles, resources, content providers, URI patterns, properties | | `activiti` | `activiti.databaseSchema.name` | Workflow engine state — running and historic process instances | | `groovy` | `groovy.databaseSchema.name` | Stored Groovy script bodies and versions | | `auditlog` | `auditlog.databaseSchema.name` | The audit log | | `batchtasks` | `batchtasks.databaseSchema.name` | Batch task definitions and run history | | `certification` | `certification.databaseSchema.name` | Access certification campaigns | | `pbac` | `pbac.databaseSchema.name` | Policy-based access control | They are versioned independently of one another, they can be configured on different hosts, and no single version number describes all seven. Two consequences reach an administrator directly. Workflow state, stored scripts and audit history are **not** in the identity schema, so a question about an in-flight approval request or about last quarter's audit trail is a question about a different schema from the one holding the user. And a restore that brings back the identity schema alone silently loses every in-flight approval request, every stored Groovy script a managed system or business rule refers to, and the entire audit trail — Flyway will not catch the mismatch, because it tracks each schema separately. Backups, restores and migrations are database work: coordinate them with whoever owns the database, and see the [Installation Guide](/installation/installation.md). There is no screen in OpenIAM that lists the seven schemas or the version each one is at, so if you need to prove those before a restore, that evidence comes from the database and not from the product. ### The queue layer Every cross-service call in OpenIAM is a RabbitMQ request/reply, over **18 vhosts** — including `openiam_idm`, `openiam_connector`, `openiam_synchronization`, `openiam_audit`, `openiam_activiti` and `openiam_common`. A queue is named for the kind of message it carries, so the provisioning-to-connector queue is literally `ProvisionConnectorQueue` on the `openiam_idm` vhost. Confirm both in the management console at `/rabbitmq`: the vhost list and the queue list are the observable form of this paragraph, and knowing the naming convention lets you find the right queue instead of guessing. Consumer counts, prefetch and the inbound message-size ceiling are set where the deployment is defined rather than in the Webconsole, and two of those blocks are throttled deliberately: raising bulk provisioning can overload the whole installation, and raising workflow initiation can exhaust the JDBC connection pool, `org.openiam.jdbc.connection.pool.size.max`, shipped `20`. Raise the pool before you raise either, and see the [Installation Guide](/installation/installation.md) for the values themselves. #### The broker reply timeout `org.openiam.mq.broker.reply.timeout` is the single most important number in this layer: it is how long a service waits for a synchronous reply before giving up with `Response is not received from RabbitMQ during reply timeout`. Two things about it are easy to get wrong. {% hint style="warning" %} **The key is not in the deployment's `rabbitmq.properties`.** The file you would edit does not contain it, so searching that file finds nothing and proves nothing. The baseline compiled into the product is `30000`, and every shipped deployment sets `120000` per service on top of it. **The effective value in a shipped deployment is 120 seconds, not 30.** No screen reports the effective value. What you can observe is the interval between the request and the timeout error, in the audit trail or the service log: roughly two minutes means the deployment's value is in force, roughly thirty seconds means something reverted to the compiled baseline. Changing it is a deployment-level change — see the [Installation Guide](/installation/installation.md), and [Where settings live](/administration-guide/start/where-settings-live.md) for why a properties file is the wrong layer to reason from here. {% endhint %} Two adjacent keys are easy to mistake for it: | Property | Baseline | What it actually is | | ------------------------------------------ | ------------------------------------------------------ | ----------------------------------------- | | `org.openiam.mq.broker.reply.timeout` | `30000` compiled, `120000` in every shipped deployment | How long to wait for a reply | | `org.openiam.mq.broker.reply.polling.time` | `50` | Reply poll interval, ms | | `org.openiam.rabbitmq.timeout` | `-1`, and in no properties file | **Connection** timeout, not reply timeout | Shipped deployments set `org.openiam.rabbitmq.timeout` to `120000` on the auth-manager service. That is the connection timeout, a different setting from the reply timeout the other services override — do not copy it expecting a longer reply wait. Also relevant when messages appear to loop: `org.openiam.rabbitmq.message.max.retry.count`, shipped `100`, counted with the `rabbitmq-message-retry-count` header, which you can read on a message in the management console. That retry serves one condition — a save that could not proceed because another save of the same user was already running. Each attempt puts the message back on the queue it came from and adds `Save is in progress. Send message back to queue. RabbitMQ exchange is ` to the operation's audit event; on the last one it gives up with `Maximum retry count exceeded. Operation interrupted. Message queue is . RabbitMQ exchange is `. So a bulk operation that appears to loop on `ProvisionBulkQueue` is usually one target user being saved from two places at once: read the audit event for the save that keeps failing rather than raising the retry count. #### Channel counts A RabbitMQ channel is a lightweight session inside a service's connection to one vhost. Every listener consumer keeps one channel open for as long as it runs, so a connection's channel count is roughly its number of listeners multiplied by the consumers each one is running. Each listener runs between `org.openiam.rabbitmq.concurrent.consumers` and `org.openiam.rabbitmq.max.concurrent.consumers` consumers and scales within that range with load. A service with 35 listeners on the `openiam_am` vhost therefore holds about 210 channels on that connection while idle, and more under load. A connection that only sends on a vhost holds about one. A high count is therefore not evidence of a leak. A count that keeps rising past the listener ceiling is. To tell the two apart, list each channel with its consumer count on the broker: {% code overflow="wrap" %} ```bash rabbitmqctl list_channels -p connection consumer_count ``` {% endcode %} If almost every channel carries one consumer, the count is listener consumers, and it is bounded. Channels with no consumer that keep accumulating are the thing to report. From 2026.10.1, each service also publishes the count itself, as the `openiam.mq.channels.open` gauge on `/actuator/prometheus`, tagged `factory` (the connection) and `vhost`. Graphed over several days, it shows whether a connection settles within its listener pools or keeps growing. Container deployments open every service's HTTP port inside the container network, so the gauge can be scraped there. A service started as a plain Java virtual machine (JVM) without a `server.port` has no HTTP endpoint to scrape. Connector response queues are the one case where listeners come and go. IDM runs one listener per connector response queue, and, from 2026.10.1, stops the listener of a connector that was deleted, moved to another queue, or had its urgent queue turned off. Before 2026.10.1 those listeners kept their channels until IDM restarted, so a deployment that edits connectors often sees its `openiam_connector` channel count grow between restarts. | Property | Shipped | What it controls | | --------------------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------- | | `org.openiam.idm.connector.queue.release.sweeptime` | `300000` | How often each IDM node stops the listeners of connector queues no longer in use, in ms | | `org.openiam.rabbitmq.connector.response.concur` | The value of `org.openiam.rabbitmq.concurrent.consumers` | Minimum consumers per connector response queue | | `org.openiam.rabbitmq.connector.response.max` | The value of `org.openiam.rabbitmq.max.concurrent.consumers` | Maximum consumers per connector response queue | | `org.openiam.rabbitmq.connector.response.prefetch` | The value of `org.openiam.rabbitmq.prefetch.count` | Prefetch count per connector response queue consumer | #### Reaching the management console The RabbitMQ management console is published *through* the gateway as `/rabbitmq` and protected by OpenIAM, so you reach it with your OpenIAM session rather than the broker's own credentials. The gateway recognises the prefix from `org.openiam.content.provider.rabbitmq.pattern` and attaches the broker as the upstream of the seeded URI pattern — which you can see for yourself under **Access Control → Content Providers**. `/grafana` works the same way when the deployment supplies Grafana's address; there is no shipped default for it. ### Connector and managed system Connector health is not a log — it is an index. OpenIAM sends a real test connection to every active, non-manual managed system on a timer, from one node only, and stores the result in the `connectorreply` index with operation `TESTCONNECTION`, deleting the entry when the managed system becomes manual or inactive. The timer is `org.openiam.idm.connector.health.check.sweeptime`, shipped `60000`. Two consequences. First, the **Running connector status** column on the managed system search screen is up to 60 seconds stale by design, so a status there is a recent answer and not a live one. Second, that same sweep is what **re-binds connector queues** after a restart in which the IDM service came up before the connector — so a connector that is running but receiving nothing often fixes itself within a minute, and if it does not, the queue binding is the thing to inspect in the management console. The opposite direction has its own sweep. From 2026.10.1, every IDM node stops consuming the response queue of a connector that no longer uses it, every `org.openiam.idm.connector.queue.release.sweeptime` ms (shipped `300000`). If the connector list cannot be read, the sweep keeps every listener. See [Channel counts](#channel-counts). ### Health checks and heartbeats Two mechanisms, because half the services do not listen on HTTP. **HTTP services** expose Spring Boot actuator, unauthenticated, from `management.endpoints.web.exposure.include`, shipped `health,prometheus,metrics`, with `endpoints.health.sensitive` shipped `false`. `/idp/actuator/health`, `/selfservice/actuator/health` and `/webconsole/actuator/health` all answer, and all three are seeded as `DEF_NONE_AUTH_RULE` URI patterns so the gateway does not demand a session for them — which you can confirm under **Access Control → Content Providers**. These three are what a load balancer should check; see [Behind a load balancer](/administration-guide/gateway/troubleshoot-the-gateway.md#behind-a-load-balancer). Three health indicators are deliberately disabled, and it matters when you are reading an `UP` result: | Indicator | Shipped | Why | | ----------------------------------------- | ------- | -------------------------------------------------------------------------------------------- | | `management.health.mail.enabled` | `false` | A bad SMTP connection string should not fail the whole health check | | `management.health.rabbit.enabled` | `false` | The stock check fails with `Cannot determine target ConnectionFactory for lookup key [null]` | | `management.health.redis.enabled` | `false` | The stock check does not print the exception; OpenIAM uses its own | | `management.health.elasticsearch.enabled` | `true` | Re-enabled once the framework fixed its reporting | So a health check reporting `UP` does **not** mean RabbitMQ, Redis or mail are working. Confirm that for yourself by reading one health response: the components those three would have contributed are simply absent from it. Check those layers directly instead. **Non-HTTP services** — `idm`, `groovy-manager`, `auth-manager`, `synchronization`, `reconciliation`, `workflow`, `audit-log-manager`, `pbac-manager`, `risk-manager`, `certification-manager`, `email-manager`, `device-manager`, `sas-manager`, `batch-task-manager`, `business-rule-manager` — do not answer an HTTP health endpoint at all. Each one writes its health to a file that the deployment's own health check reads, on the timer `org.openiam.health.check.sweeptime`, shipped `60000`. There is no Webconsole screen for these, and reading the files themselves is deployment-level work: see the [Installation Guide](/installation/installation.md). From an administrator's seat, the observable evidence that one of these services is alive is its own effect — a provisioning operation that completes, a batch task whose last execution time advances, a certification campaign that generates. Connector heartbeat is separate again: `org.openiam.idm.connector.health.check.sweeptime`, shipped `60000`, as described in the connector layer above. ## Related * [Which log answers which question](/administration-guide/operations/which-log-to-read.md) — routes a symptom to the log that holds the answer * [Find audit evidence](/administration-guide/operations/find-audit-evidence.md) — the audit record model, the search parameters, and following a parent id * [Rebuild a search index](/administration-guide/operations/rebuild-a-search-index.md) — when search cannot find an object that is present and correct * [Rebuild the authorization graph](/administration-guide/operations/rebuild-the-authorization-graph.md) — when membership is right and effective access is wrong * [Error and symptom index](/administration-guide/error-and-symptom-index.md) — the verbatim error strings, and the page that explains each one * [Installation Guide](/installation/installation.md) — service logs, container and manifest settings, database backup and restore, timezone changes below the UI *Applies to OpenIAM 2026.8.1. Last reviewed 29 September 2026.* --- # 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/administration-guide/operations/diagnose-a-failed-operation.md?ask=&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.