Introduction
The Operations Center is the live cluster-health screen of NoSqlStudio's Cosmos Optimizer workspace. It does for Azure Cosmos DB for MongoDB what mongostat + Atlas Performance Advisor combined try to do for vanilla MongoDB — but in real time, with cost telemetry built in, anomaly detection at every tick, one-click drill into the offending query, and a built-in AI advisor that turns each anomaly into a concrete remediation.
What you see when you open it
- Six live charts, each ticking every second: RU/s, throttles (HTTP 429), p99 latency, error count, projected $/hour cost, top-partition share.
- An anomalies badge in the toolbar — clickable, with a row-per-anomaly menu that lets you jump straight to the offending data.
- A Detected anomalies grid below the charts: every anomaly the detector saw in the last hour, paginated, click-to-drill.
- Recording controls — Start / Stop, schedule a duration, see a pulsing REC pill while it runs.
- History on — turn live mode off and replay any window of recorded snapshots with a DVR-style scrubber.
- A gear ⚙ with a status dot — wires the recording stream to your MongoDB management database so history travels across machines.
Prerequisites
Heads-up
You must have Log Analytics wired up first
The six charts read from Azure Log Analytics. If you haven't followed the [Cosmos Log Analytics setup guide](/docs/cosmos-log-analytics) yet, the charts will be flat zeros and you'll see a yellow No telemetry captured yet banner. Do that 5-minute setup first — this manual assumes it's done.
You'll need:
- 1An open connection to a Cosmos DB for MongoDB account.
- 2Cloud Credentials filled in (the six fields from the setup guide).
- 3Optional: a MongoDB management database configured in Settings → Database if you want session history mirrored across machines.
How to read this manual
Each step has Do, See, Why — same as every NoSqlStudio doc. 💡 boxes explain concepts on first use; ⚠️ callouts flag the sharp edges. Estimated time end-to-end: ~30 minutes, or ~10 minutes if you skim and skip the conceptual asides.
Open the Operations Center
From any open Cosmos connection
From the menu: Tools → Cosmos Optimizer (shortcut: Ctrl + Alt + Shift + O).
A new workspace tab opens with a left sidebar grouped into four sections: Diagnostics, Cost & Capacity, Operations, Configuration. The Operations Center is the first item under Diagnostics, pre-selected by default.
We promoted the Operations Center to the default landing pane in 2026-05 — it's the screen DBAs reach for first when troubleshooting a flaky Cosmos account. The 10 other panes are drill-downs from here.
Anatomy of the toolbar
Left-to-right across the top of the pane:
- Operations Center — realtime cluster health — title with the chart-range selector to the right (1m / 5m / 15m / 30m / 1h).
- Anomaly badge — yellow when ≥1 anomaly is active, red when ≥1 is
highseverity. Click it: a row-per-anomaly menu drops down. - Idle / REC pill — turns red and pulses while a recording is in progress.
- Start recording / Stop recording button.
- History on — toggle into replay mode (Stage 4).
- Gear ⚙ + status dot — green = mirror healthy, amber = unreachable, blue = connecting, grey = file-only (no mirror configured).
The six charts — what they mean and how to read them
Each chart is fed by the Log Analytics bridge — a 60-second poll that reads CDBMongoRequests and re-stamps timestamps to wall-clock now. The bridge windows the last 1 hour of traffic; the chart's visible range is whatever you picked in the chart-range selector.
Concept
Per-chart options
Every chart has two pickers above it: chart mode (Line / Area / Bar / Big-number / Gauge) and 2D / 3D. Your choices persist per-metric in localStorage — pick once, it sticks across reloads.
RU/s Consumed
Total Request Units consumed per second, summed across every operation the account serviced in that tick. The single metric every Cosmos DBA tracks first — it's the dollar-amount, the throttle precursor, and the workload character all at once.
Concept
What is an RU?
A Request Unit is Cosmos's normalised cost-of-a-read unit. 1 RU ≈ 1 KB point read of a 1 KB document. Inserts cost ~5 RU, updates ~10, expensive aggregates can run hundreds of thousands. You provision a RU/s ceiling on your account; exceed it for too long and Cosmos starts returning 429 Too Many Requests — that's a throttle.
Steady-state shape varies hugely by workload — read-heavy SaaS hovers at 200-2000 RU/s; an analytics export job can hit 80 000+ RU/s in bursts. Look for sudden cliffs (cache restart, deploy) or sustained climbs (memory leak retrying queries).
Throttles (HTTP 429)
Count of 429 Too Many Requests responses Cosmos returned, per second. Each one represents a request your app had to retry — adding tail latency, RU cost on the retry, and risk of cascading failure if the app doesn't back off.
Concept
Three kinds of throttle
Click any 429 dot to open the Throttling RCA drill. The detector classifies each storm into one of: hot-partition / key saturation (a single key got hammered), burstable-cap overdraft (autoscale didn't keep up), expensive query spike (one $50k-RU aggregation), cluster-wide undersized (chronic), or distributed saturation (spread across keys but still hitting the ceiling).
Heads-up
Even one persistent 429/s for >10 minutes is worth investigating. Cosmos retries are NOT free — they're billed at the same RU rate as the original request.
Latency p99
The 99th percentile request duration, in milliseconds, over a 5-second sliding window. p99 is the tail — the experience the 1% of your users with the worst luck are having right now.
Read-only point reads should sit at <15 ms all day. Queries with a missing index easily hit 100-500 ms. Cross-partition aggregates routinely cross 1 000 ms. Anything over 2 000 ms is almost certainly a missing composite index — click the dot to open Composite Index with an Explain prefilled.
Error Count
Count of non-2xx, non-429 responses per second. Includes 401 / 403 (auth), 404 (namespace not found), 410 (account being moved), 500/503 (Azure-side incidents).
Concept
Click an error dot to open Diagnostic Logs (KQL) with a pre-built KQL query that groups by status code and shows 10 sample requests per group — enough to spot a misconfigured client or a redeploy with stale credentials.
Cost (projected $/hr)
An extrapolation: current_RU_per_sec × 3600 × $_per_RU. The $_per_RU rate defaults to $0.00000025 (Cosmos Serverless pricing); change it in Cloud Credentials if you're on Autoscale (~0.18× cheaper) or Provisioned (~0.10×).
Heads-up
It's a projection, not your bill
The hourly $ rate assumes your current RU/s stays flat for the rest of the hour. A 30-second burst spike will inflate it briefly. Look at the shape of the projection over the last hour — that's the realistic bill rate.
Top partition share
Percentage of total RU/s consumed by the busiest logical partition. 100% means one partition is doing all the work — a textbook hot partition. Below 30% means traffic is well-distributed.
Concept
Default gauge mode
This metric ships in Gauge mode by default, not Line. Reads as a half-filled radial meter — at-a-glance, you see whether the partition split is healthy without parsing a chart.
Click any spike → Hot Partitions opens with a re-partition simulator: samples 500 docs, finds the top-5 cardinality keys, hashes them into 20 logical partitions, and shows the Gini coefficient for each candidate partition key. Pick the one that flattens the gauge.
The anomaly detector — six kinds of trouble
The detector runs every tick. It looks at the last 30 snapshots and flags six kinds of anomaly. Each one gets a severity (low / medium / high), a reason, and a destination pane for drilldown. The detector is intentionally noisy on the side of false positives — better to flag a non-issue than miss a 4 AM throttle storm.
The six anomaly kinds and their destinations
- `ru-saturation` — RU/s near or above the configured ceiling for 30+ seconds. Destination: RU Budget with the time window pre-filtered.
- `cost-spike` — projected $/hr above the cost policy threshold. Destination: Query Cost with the most-expensive captured query pre-loaded for Explain.
- `throttle-storm` — sustained 429s with classification. Destination: Throttling RCA.
- `latency-spike` — p99 above a threshold for 60+ seconds. Destination: Composite Index with Explain pre-loaded (COLLSCAN / SORT / low-selectivity FETCH detector).
- `partition-skew` — top partition share >50% sustained. Destination: Hot Partitions with the re-partition simulator.
- `error-spike` — non-2xx non-429 errors >5/s. Destination: Diagnostic Logs (KQL) with errors grouped by status code.
The anomalies badge in the toolbar
When the badge shows 5 anomalies ▾, click it.
A portal menu drops down with one row per anomaly. Each row shows severity (red / yellow), kind, namespace, and a one-line reason. Click any row.
The click opens the destination pane in a new tab, with the anomaly's metadata (namespace, time window) pre-loaded so the drill is one click away from a fix. Your live Operations Center tab keeps recording.
The Detected anomalies grid (below the charts)
Below the six sparklines, a paginated grid lists every anomaly. Default 20 rows/page, configurable 10-100. Columns: SEVERITY · KIND · WHEN · NAMESPACE · METRIC · REASON · Show ... button · AI RCA.
Click any Show ... button (or the row itself).
Same as the toolbar menu — opens the destination pane in a new tab with the anomaly pre-loaded. The AI RCA button on the right opens the same destination but auto-runs the AI advisor at the end of the drill (combobox provider picker → structured remediation plan).
From anomaly to root cause to fix
Every destination pane the anomaly grid sends you to follows the same three-act flow: Identify (you see the offending data), Inspect (you run an Explain / classify the cause / simulate the fix), AI Analyze (an LLM turns the data into a written remediation, staged in a shadow collection before any production write).
Example — Cost spike → Query Cost drill
Generate a synthetic cost spike: click the AI RCA button on a cost-spike row.
The new tab opens at Query Cost. At the top, a Cost-spike RCA — explain offending query card runs runCommand({explain: cmd, verbosity: 'executionStats'}) against the most-expensive recently-captured query. Below: the AI Advisor card with provider picker (OpenAI ChatGPT / Anthropic Claude / Azure OpenAI / Google Gemini / etc., from a combobox).
Concept
What the AI sees
The advisor gets: (a) the captured command JSON, (b) the explain output (executionStats — keys examined, docs examined, index hint), (c) the RU charge, (d) the collection name. It returns: root cause + specific fix — usually a named compound index or a query refactor. Token cost: ~600-1200 in, ~400-800 out per call.
Click any Top query shapes grid row at the bottom of the pane.
An inline panel opens below the table with the actual captured query text — the raw PIICommandText from Log Analytics, ready to Explain or copy into a debugger. Copy / Close buttons in the top right.
Example — Throttle storm → Throttling RCA classifier
From a throttle-storm anomaly row → click AI RCA.
The Throttling RCA pane opens, running the classifier: it buckets the last hour of 429s by partition key, by command shape, by ratio against the provisioned ceiling, and reports one of the five throttle categories with concrete evidence.
Example classifier verdict (paraphrased):
Pattern: hot-partition-or-key-saturation
Evidence: 73% of throttled requests target shard key '/customerId/12345'
Recommendation: This is a hot partition. Consider:
• re-keying to a higher-cardinality field (the Hot Partitions pane has a re-partition simulator)
• using TTL on the specific docs being hammered
• scaling provisioned RU/s temporarily until repartition lands
Avg RU charge of throttled ops: 217 (suggests the query is genuinely costly — not a thundering herd of cheap reads)AI shadow validation
Concept
Why we never auto-apply AI suggestions
Every recommendation that touches data is staged in a shadow collection first. The AI writes a plan, the user reviews + approves, and only then is the production object (an index, a TTL, a re-keyed copy) materialised. Every approval is also written to the audit log with the AI's full reasoning attached — your compliance team will thank you.
Recording sessions — turn live into history
The six charts hold the last hour in memory. Anything older is lost unless you start a recording. A recording captures every 1-second snapshot to disk (the ring buffer file in %APPDATA%/NoSqlStudio Dev Local/cosmos-ops-history.json, capped at 100 000 entries ≈ 28 hours @ 1 s) AND — if a management database is configured — mirrors each snapshot to the collection cosmos_ops_snapshots for cross-machine replay.
Start a recording
Click Start recording in the toolbar. A modal opens with three modes:
- ∞ Infinite — runs until you click Stop. Best for ad-hoc capture during an incident.
- ⏱ Duration — auto-stops after N minutes. Pick from presets: 15 min, 30 min, 1h, 2h, 4h, 8h, 24h.
- 📅 Scheduled — auto-stops at a specific time. Use for planned windows (a scheduled deploy, an export job).
Pick a mode, click Start.
The toolbar pill flips from IDLE (grey) to REC (red, pulsing). The label shows ends May 27, 03:15 AM if you picked Duration or Scheduled. The recording is also visible in Job Manager → Monitoring, filtered as Cosmos Ops.
Concept
Recording survives navigation
Once started, the recording keeps capturing even if you close the Operations Center pane — the ticker is held by a refcount inside the recorder module, not by the React component. You can navigate to another workspace tab and come back; sample counts will have continued ticking.
Watch the sample count climb in Job Manager
Open Tools → Job Manager (or its shortcut). Click the Monitoring tab. Filter by Cosmos Ops in the kind picker.
Your recording appears as a running row. The TIME column shows elapsed seconds + the sample count, updated every 5 seconds. The status pill is red while running, green when completed.
Concept
Job Manager is the system of record
We deleted the redundant inline History panel inside the Operations Center — past recordings live exclusively in Job Manager → Monitoring now. One source of truth instead of two.
Stop a recording
Click Stop recording in the toolbar (or wait for the Duration / Scheduled auto-stop).
The pill returns to IDLE (grey). The Job Manager row flips to completed with the final sample count. The 5-second batch buffer is flushed (no trailing ticks are lost).
The 5-second batch is the trade-off between IPC chatter (1 round-trip / batch instead of 1 / tick) and crash-window risk (worst case 5 seconds lost on a hard kill).
Replay recorded sessions (History on)
Switch into history mode
Click History on in the toolbar.
The live body of the pane is replaced by the history scrubber view: an amber top stripe, RANGE preset buttons (Last hour / Last 24h / Last 7d / All), a source pill (Cloud when mirror is healthy, Folder when file-only), the HistoryModeBanner with Playing history · 1×, a DVR-style scrubber, speed selector (1× / 2× / 5× / 10×), and the same six sparklines reading from the chosen historical slice.
Scrub through a recording
Drag the scrubber. Or click play and let it auto-advance at the picked speed.
The charts redraw as you scrub: each frame is a snapshot from the recording. At 1× the playback speed matches wall-clock — 5 minutes of recording = 5 minutes of playback. At 10× a one-hour recording plays in six minutes.
Concept
Where the data comes from
Cloud pill: the IPC returned the union of disk-local ring-buffer entries + management-DB mirror entries (de-duplicated by _id). That's how you see recordings made on other machines. Folder pill: mirror unconfigured or unreachable; only your local disk.
Back to live
Click ← Back to live in the history-view toolbar.
Same data, same sparklines, but ticking forward again at 1 Hz.
Wire the recording stream to your MongoDB
By default, recordings land on disk only in cosmos-ops-history.json. To share history across machines + team members, mirror it to a MongoDB management database. Same pattern as Mongostat / Realtime / Currentop / Mongotop / Profiler — once configured at the app level (Settings → Database), every monitoring screen exposes a per-screen opt-in checkbox.
Open the gear ⚙
Click the gear icon at the top-right of the Operations Center toolbar (next to History on, with a coloured status dot).
The Operations Center recording storage modal opens. Two cases:
- 1Management database NOT configured — info banner pointing you to Settings → Database. Click Open Settings, paste your MongoDB URI, save. Come back here.
- 2Configured — a masked URI is shown, a checkbox Mirror recorded snapshots to the management database (default on), a live status banner (
Connected — recorded snapshots are being mirroredin green,Connecting…in blue,Unreachable — recording locally onlyin amber), and a red Clear recorded history button.
How the mirror works under the hood
Concept
File primary, Mongo mirror
The disk file is always written, in every mode. The Mongo mirror is purely additive — bulkWrite of replaceOne upserts keyed by _id. If Mongo is unreachable at boot or drops mid-session, NoSqlStudio keeps recording to disk and emits one status event on the healthy↔unreachable transition. On reconnect, reconcileUp pushes the entire disk ring back up — dedupe is free because the upsert key is stable (<conn>:<jobId>:<ts>).
TTL: each mirrored document carries a createdAt field with a 30-day TTL index — the workspace prunes automatically. Workspace cap (MAX_EVENTS = 100 000) corresponds to ~28 hours at 1 s tick; with the mirror configured, full history is preserved for the TTL window even if you record continuously for weeks.
Clear recorded history
In the gear modal, click Clear recorded history. Confirm the prompt.
Both the disk file AND the cosmos_ops_snapshots collection are emptied. The History on view goes blank until a new recording is started.
Heads-up
This is irrevocable. If the management DB is down at the moment you click Clear, the targeted deletes are queued in a pending-deletes file on disk and flushed on the next reconnect — so a delete is never silently lost.
Tips and tricks
Collapse the No-telemetry banner
If your Cosmos account is genuinely idle (overnight, dev env), the yellow No telemetry captured yet guidance banner gets in the way. Click the ▼ chevron next to its title — the long body collapses to a single-line strip. Choice persists per session. The six sparklines below reflow to fill the freed space automatically.
Resize the sidebar
Drag the right edge of the Cosmos Optimizer sidebar to whatever width you want (clamped between 60px and 80% of the window). Persists in localStorage per app, across reloads.
Chart 2D / 3D / mode picker
Click the 2D pill on any chart to flip it to 3D (real depth-faced bars / lines via SVG polygons + CSS perspective — not just a tilt). Click the Line ▾ dropdown to switch mode: Line, Area, Bar, Big-number (just the latest value), Gauge (radial fill for 0-100% metrics). Per-chart, per-metric, persisted.
Configure cost rate (Serverless vs Autoscale vs Provisioned)
Cosmos pricing varies dramatically by mode. Open Cloud Credentials → Cost rate at the bottom of the pane → three presets (Serverless / Autoscale / Provisioned) plus a custom field. The Cost ($/hr) chart and Cost-spike anomaly threshold both honour this value — set it once per connection.
When you're done — clean up
Stop a running recording
Click Stop recording in the toolbar. Or open Job Manager → Monitoring, right-click the row, Cancel. Either way the 5-second buffer is flushed before the job is marked completed.
Free disk space
The disk ring buffer caps at 100 000 entries (~28 hours) so it cannot grow unbounded. If you want to wipe it manually: gear ⚙ → Clear recorded history.
Stop mirroring to MongoDB
Gear ⚙ → uncheck Mirror recorded snapshots to the management database → Save. Disk file keeps growing as before; nothing new lands in the management DB. Already-mirrored documents stay until their 30-day TTL expires.
Summary — the Operations Center workflow
| Phase | Action | Outcome |
|---|---|---|
| Setup | [Wire Log Analytics once](/docs/cosmos-log-analytics) | Six live charts populated |
| Live monitoring | Open the pane, watch the charts, click any anomaly | Three-click drill from symptom to root cause |
| RCA | Use the per-anomaly destination pane + AI Advisor combobox | Structured remediation with shadow-validation safety net |
| History | Start recording → optionally configure Mongo mirror → History on to scrub | 30-day team-wide history of every tick |
| Hygiene | Job Manager → Monitoring → review past recordings; gear ⚙ → Clear when needed | Disk + Mongo stay manageable |