FEATURES

Database observability, end to end.

From cluster health to query intelligence, backup verification to cost optimization — everything DBAs and SREs need on a single pane of glass.

01

See what is happening

Topology, performance and the event stream — the environment as it is now, and over the last 30 days.

REAL-TIME

See your cluster topology, live

Watch primaries, replicas, arbiters and shards on a real-time map. Catch failovers instantly and rebuild replication chains in seconds.

Auto-discovery — entire cluster topology drawn from one command
Streaming + logical replication, sharding, replica sets
Track failover/promotion events historically
<2s
failover detection
14
engine support
100%
auto-discovery
The ClusterEye Clusters screen: clusters by engine, member health and topology links
PERFORMANCE

Wait events & query performance

Track IO, lock, and CPU wait events at second granularity. Which query, which user, which host slowed down — drill in with one click.

p50/p95/p99 latency, QPS, transaction rate
Top-N breakdown by user, host, database, schema
Rolling 90-day historical profile
1s
granularity
90d
retention
p99
track
Database time by query: the hourly stacked chart, the typical band and each heavy statement's share
NEW

Operations Timeline — what happened in your environment?

Alarms, metric anomalies, configuration changes, deployments and schema activity flow into a single timeline. The correlation engine automatically groups related events into incidents and flags the likely root cause — answering "what happened last night?" takes seconds, not minutes.

Unified event stream across every engine: alarms, metrics, queries, schema, config, replication
Correlation-based incident grouping with confidence-scored root cause suggestions
Live mode, historical replay and MTTR tracking
AI Alarm Investigator — investigates an incident with a local (air-gapped) model over stored evidence only
1
unified timeline
auto
incident grouping
RCA
root cause hints
ClusterEye Operations Timeline: the event density chart and incident records with their root cause
02

Find out why

Anomaly detection, query intelligence and the dependency graph: the path from an alert to a root cause.

AI

AI-driven query optimization

Catching slow queries isn't enough — ClusterEye explains them automatically, analyzes plans, and produces verified index suggestions.

EXPLAIN plan visualization + cost analysis
Index and statistics suggestions (PostgreSQL, MongoDB, MSSQL)
Pattern-based aggregation via query fingerprints
EXPLAIN
plan analysis
HypoPG
index validation
AI
advisor
ClusterEye Intelligence Center: active instance anomalies, root-cause candidates and the evidence list
ALERTS

Noise-free, anomaly-based alerts

Static thresholds are dead. ClusterEye learns your normal — replication lag, deadlocks, disk I/O — and pages you only when it actually matters.

Seasonality awareness (hour/day/week)
Slack, PagerDuty, Opsgenie, Webhook integrations
Correlation — groups related alerts into one incident
Evidence-grounded AI investigation — one click from an alarm, with competing hypotheses and evidence citations
dow×hour
seasonal baseline
5+
channels
P0–P3
priority
From the alert list to the correlated incident, then to the root-cause card pointing at a configuration change
GRAPH

What breaks if I touch this table?

The Database Context Graph continuously maps running statements to the objects they touch. Open a table and you see the queries that read and write it, each one's load over the last 24 hours and how it reaches the data — a seek or a full scan — so "who still uses this?" is answered before a schema change, not guessed. It reads the other way too: from a statement down to the tables, indexes and plans it depends on.

Object impact: "Dropping this table affects 10 queries — 4 write to it", as a diagram or a table
Honest edges: reads and writes are separated, and an edge says whether it came from an execution plan or was inferred from the query text; historical dependencies are marked as such
Query to object: a statement's waits, plans, the tables it touches and its neighbouring statements, in one drawer
PostgreSQL, SQL Server, Oracle, MySQL, ClickHouse and MongoDB
A "what the graph can't know" section names what is missing: untracked statements, and code that has not run yet
6
engines
24h
load window
0
guesswork
Object Impact: the diagram of the 10 queries that depend on the orders table, and the same dependencies as a table
03

Protect the data and the audit trail

Prove the backup actually restores, and keep a record of who changed what.

BACKUP

Prove your backup health with real data

Knowing you took a backup isn't enough — ClusterEye runs automated restore tests and accumulates evidence against your RPO/RTO targets.

Automated test restores (in a sandbox cluster)
RPO/RTO compliance reports
PITR + full backup + log shipping view
PITR
coverage
24/7
verify
RPO/RTO
reporting
SECURITY

Security audit for compliance

Continuously scan for unauthorized access, open ports, critical CVEs, and weak password policies. Out-of-the-box reports for SOC 2, ISO 27001, GDPR and PCI-DSS.

Continuous CVE scan + patch suggestions
RBAC, SAML SSO, audit log integration
Compliance scorecards (SOC 2, ISO, GDPR)
5+
frameworks
24/7
scan
SAML
SSO
ClusterEye Security Compliance: the compliance score, the category breakdown and the riskiest nodes
AUDIT

Activity monitoring: who changed what, from where?

The Audit Investigation Center scores Oracle and MSSQL activity by risk in one audit trail: bulk deletes, after-hours activity, shared service accounts and failed statements surface instantly. On Oracle the source is Unified Auditing; on MSSQL the traffic is captured off the network — without connecting to the database, without turning on Extended Events or a trace, and without measurable load on the server.

Automatic risk score on every record (bulk, after-hours, shared-account signals)
User / object / program breakdowns, full-text SQL search and activity timeline
Passwords and tokens are masked before anything leaves the host; SQL text can be dropped entirely
CSV, JSON and PDF report exports + SIEM integration, read-only auditor role
2
engines
risk
scoring
0
footprint on the DB
04

Provision and keep alive

Beyond monitoring: standing clusters up and running them for their whole life.

FLEET

Database Fleet — provision the database, then keep it alive

The part of ClusterEye that is not monitoring: it provisions PostgreSQL (Patroni HA, streaming replication), MongoDB (replica sets, sharded clusters) and MySQL (InnoDB Cluster) onto your own servers, then operates them — adding and removing members and shards, rolling upgrades, switchovers, credential rotation and pgBackRest backups. Every operation runs through a state machine from preflight to validation, and a failed step rolls the completed ones back automatically. The last provisioning step installs the agent, so a cluster is monitored from the moment it exists.

Production topologies for PostgreSQL, MongoDB and MySQL (ClickHouse on the roadmap)
Day-2: add members and shards, rolling upgrades, switchover, backups, decommission
Preflight → deploy → validation state machine with automatic rollback on failure
3
engines (live)
auto
rollback
0
manual monitoring setup
05

What you have, and what it costs

Find the databases in your cloud and on your network, then measure their capacity and their bill.

CLOUD

Every database in your cloud account, in one list

Cloud Estate scans the cloud accounts you connect, read-only, and inventories their managed database services. Its real value is answering one question: which of these is nobody monitoring? Coverage gaps, publicly reachable instances and recent changes are each called out.

Read-only connection — nothing is exposed to the internet and no configuration is changed
Coverage gaps: it exists in the cloud but is not monitored in ClusterEye
Public accessibility and recent changes are flagged
Put a discovered database under monitoring from the same screen
read-only
access
gap
detection
multi
account
DISCOVERY

Find the databases that never made it into the inventory

Nobody can honestly claim to know every database they run. Network Discovery scans the IP ranges you give it, fingerprints the services on open ports at the protocol level to tell which engine they are, and separates the managed from the unmanaged. It works without credentials; give it credentials and the version becomes exact.

CIDR scan jobs, scan profiles and scheduling
Protocol fingerprinting for engine identification, with a confidence score
Managed / unmanaged / not seen recently, kept apart
Optional SSH for exact version detection
credential-less
scanning
confidence
scored
CIDR
ranges
OPTIMIZE

Reclaim over-allocated capacity, with the measurement to back it

Thirty days of CPU and memory usage are compared against allocated capacity. Every node gets a verdict — over-provisioned, right-sized or under-provisioned — and the verdict carries a confidence. Nodes that are new or short on history are marked as still learning rather than guessed at.

Allocated → recommended vCPU and memory, per node
Total reclaimable CPU and memory, and how it moved over time
Under-provisioned nodes are surfaced on the same screen
Thresholds are set by policy, and no advice is issued without measurement
30d
p95 window
verdict
+ confidence
both ways
over and under
Resource Optimization: 30 days of usage against allocated capacity, with a per-node verdict and confidence
COST

What your managed databases actually cost

Cost Intelligence reads your cloud bill and breaks the cost down to the individual database. Instead of the service totals a cloud console shows, you get the answer to "what did this cluster cost this month" — and read next to the right-sizing verdicts, it puts a number on the capacity you could reclaim.

Taken from the bill — real consumption, not a price-list estimate
Per-database and per-account breakdown over a date range you choose
Reads alongside the resource optimization verdicts
bill
sourced
per-DB
breakdown
AWS
+ Huawei

See it all in 5 minutes.

Start free. No credit card, no commitment.

Start freeSchedule a demo