Content Central feels slow: report it so it gets fixed fast
Turn a vague 'it's slow' into one timed, reproducible sample — plus the matching logs if you're an administrator — so support can find the cause instead of guessing.
At the end of this guide you'll have one timed, reproducible sample of the slowness — plus the matching server logs if you're an administrator — which is the difference between a fix in days and a ticket that never closes.
Why one timed sample beats "the server is slow"
"Content Central is slow" can't be investigated — there's no moment to line anything up against. But "opening the Invoices folder took from 2:14:05 to 2:14:47 PM for me in Chrome, and it's fast for my colleague" lets support match that exact minute against logs, and that's how real causes get found: a spinner that turned out to be sessions queuing for licenses, folder browsing dragged down by years of accumulated version history, a report that was fast until one added field made it do extra work for every row. None of those are guessable from a description — and reports that stay vague tend to stay unsolved.
A generic "everything is slow" dump gives support thousands of log lines and no anchor. One timed sample tells them exactly where to look.
Step 1 — Pick one action and time it
Choose one action that feels slow — just one: opening a specific folder, running a specific search, loading a specific report, or uploading a document.
Write down who is doing it (username) and which browser, including the version.
Do the action once and record the exact clock time it started and finished — seconds matter, and include your time zone. Your phone's clock is fine.
Note the exact target: which catalog, which folder / search terms / report name, and roughly how big the result is (about how many documents or rows, or the file size of the upload).
Ask a colleague to do the same action and note whether it's slow for them too. "Only me" and "everyone" point support in completely different directions.
Capture a short screen recording of the action — on Windows,
Win+Gopens the built-in screen recorder, and a phone video of the screen works too.
What you should see: one sentence you could hand to anyone — "Searching invoice 2026 in the Accounting catalog took 40 seconds (9:03:10–9:03:50 AM EST) for dana.r in Edge; instant for sam.k" — plus a recording that proves it. That is a complete sample. If you're not an administrator, skip ahead to the evidence packet.
You can also screenshot your own activity around that time: open the Event Viewer from your user menu and filter to the relevant Action. (If you don't see it, your account needs the Event Viewer permission.)
If something looks stuck: capture it, don't clean it up
When a batch, a document, or a queue looks frozen, do not delete it or restart services to "clean things up." Deleting destroys the only evidence of the cause, and interrupting work midway can leave partial state behind — like a half-updated index or an incomplete job — and can orphan data. Write down the identifiers (batch name, document name or number, which queue) and the timestamps, take a screenshot, and leave it alone until support has seen it.
Step 2 (administrators) — Line up the server-side view
If you're the administrator — or can forward this section to them — grab the pieces the sample alone can't show, for that exact time window.
In Content Central, open the Event Viewer from your user menu — administrators get additional filters across everyone's activity. Set the From and To dates around the sample, pick the affected user, and filter by Action if relevant.
What you should see: a table of events for the affected user covering the window, with each action and its date and time. If it comes back empty, widen the dates or clear the Action filter.
Admin Event Viewer with From/To dates set around the slow sample and events listed for the affected user
Open Admin > System Health. Note the overall status and any subsystem check flagged as unhealthy, then use the diagnostics bundle System Health offers — a preview shows exactly what will be collected, nothing downloads until you confirm, and the
.zipsaves only to your computer so you can forward it to support.noteA stopped background service — the one that maintains the search index, for example — can quietly make Content Central feel slow or stale without anything looking "broken." System Health is the fastest place to spot an unhealthy subsystem.
On the Content Central server, open Windows Event Viewer and save the Application and System logs for the sample's window, plus the log under Applications and Services Logs > ContentCentral (its sources start with
AdmCC).
While the slowness is happening (or the next time it does), open Task Manager or Resource Monitor on the server and screenshot CPU, memory, and disk for the IIS worker process (
w3wp.exe) and the Ademero Content Central services.
Task Manager Details view showing w3wp.exe and the Ademero Content Central services with CPU, memory, and disk columns visible
Still stuck? Send this evidence packet
Put everything in one message to support:
- The one-sentence sample: the action, catalog + folder / search / report name, who, browser, and exact start and end clock time with time zone
- Approximate result size (documents, rows, or MB)
- Whether a colleague reproduces it, and whether it happens all day or only at certain times
- The screen recording
- (Admin) The Event Viewer screenshot for the window, the diagnostics bundle
.zip, the Windows log exports, and the CPU/memory/disk screenshot - (If anything looks stuck) the batch/document/queue identifiers and timestamps — left in place, not deleted
With that packet, support can line your sample up against the logs on the first pass instead of asking you to catch it again.