What Leads to Blind Spots in Monitoring Hyland OnBase Systems?

01 — The Causes

What leads to blind spots in monitoring Hyland OnBase systems?

Five places where the console reads green and the process has stopped.

Across the OnBase estates we observe, the blind spots cluster into five causes. Each one has the same signature: a native view that answers a narrower question than the one the business is asking. The Reveille for OnBase Technical Overview lists the tests that cover each of them; the short version is below.

1. Workflow timers that never fire

What the console shows: the timer is configured, the Workflow service is running. What it cannot show: that the timer did not execute at its scheduled time, or executed and errored. A timer that never ran produces no error, no log line and no alert. It produces a queue that quietly stops draining, discovered by whoever was waiting on the other end.

2. Batches that stop moving

What the console shows: capture services up, DIP process scheduled. What it cannot show: how many batches are uncommitted, how many documents are awaiting export, which batches have sat untouched for more than a day, and whether a Batch Lock or Disk Group lock is the reason. OnBase fails by absence here. The import did not error; it simply did not happen. We covered the DIP version of this in OnBase DIP not importing documents.

3. Client response that only the user measures

What the console shows: Application Server responding, IIS pools healthy. What it cannot show: how long Web Client login, search, retrieve and logout actually take right now, or whether the Unity Client can retrieve a document at all. Nothing in the platform runs those transactions on a schedule from the user’s side. So the measurement happens at the help desk. The Unity Client troubleshooting post is a catalogue of exactly this.

4. Integration edges outside the OnBase log

What the console shows: OnBase. What it cannot show: the partner Unity API application, the custom REST service, the LOB server, the shared folder an ERP drops files into, the web service a claims system calls. When the business process spans OnBase and three other systems, the failure usually lands in the handoff, and the handoff belongs to nobody’s dashboard.

5. Who accessed what, and the ceilings nobody watches

What the console shows: a security log, a license count. What it cannot show: the same user retrieving documents from two IP addresses in the same hour, a spike in document access volume by one account, or license usage approaching the ceiling before users get turned away. These are patterns over time. A log is a list.

02 — The Wrong Fix

Why doesn’t infrastructure or APM monitoring close the gap?

Because it does not know what OnBase is.

The usual response to a blind spot is to point the infrastructure tool at the OnBase servers. That gets CPU, memory, disk, service state and HTTP response time. It is worth having. It does not know what a Disk Group is, cannot count uncommitted batches, cannot tell a timer that ran from one that did not, and has no idea which document a user opened. Those are OnBase conditions. They need OnBase-aware tests, and the infrastructure tool has none.

Application performance monitoring moves the line but does not cross it. It traces a transaction segment and reports its response time. It still does not read the OnBase database for timer state, batch state or lock state, and it needs an agent on every server to do what it does. We wrote up where each class of tool stops in Vendor-Native Tools vs. Content Observability.

03 — The Answer

What does closing OnBase blind spots look like?

Test the work, not just the platform, and do it without touching the platform.

This is the problem Content Observability exists to solve: continuous, application-aware observation of the content layer, from the server through the workflow to the user. For OnBase that means scheduled tests that check Workflow Timer Never Ran and Workflow Timer Errors, count Uncommitted Batches and Documents Awaiting Export, time Web Client and Unity Client login, search and retrieve, exercise the REST API end to end, watch Disk Group and Process Locks, track License Usage, and flag Same User Different IP. It means doing all of it agentlessly, so nothing is installed on the OnBase servers and nothing changes the state of the platform.

04 — The Point

Where should an OnBase team start?

With the five questions the console cannot answer.

Ask, for your environment, who would know today if a Workflow Timer did not run. Who would know a batch has sat uncommitted since Friday. Who would know Unity Client retrieve went from two seconds to twenty. Who would know the ERP stopped dropping files. Who would know one account read 4,000 documents overnight.

If the answer to any of those is the user, that is the blind spot. The console boundary does not move on its own. Something has to be placed on the other side of it.