Database Events — Cluster Activity Timeline
TL;DR — The Events tab shows every lifecycle change for your cluster — created, resized, restored, backed up, failed over — in reverse chronological order. Use it to audit who changed what and to correlate dashboard alerts with platform actions.
Where to Find It
- Open the cluster
- Click the Events tab
You'll see a timeline of cards, newest first.
What Each Card Shows
| Field | Example |
|---|---|
| Coloured dot | A unique colour per event type — easy to scan |
| Label | Human-readable description (e.g. Cluster Resized) |
| Event code | The internal event type (e.g. cluster_resize) |
| Timestamp | When the event occurred (UTC) |
Event Types
| Event Code | Label | What It Means |
|---|---|---|
cluster_create | Cluster Created | The cluster finished provisioning and reached "Online" |
cluster_update | Configuration Updated | A config change was applied (firewall, pool, user, etc.) |
cluster_delete | Cluster Deleted | The cluster was destroyed |
cluster_resize | Cluster Resized | The cluster was upgraded to a new tier or size |
cluster_restore | Cluster Restored | A restore from backup completed |
cluster_maintenance | Maintenance Performed | Automated patching ran during your maintenance window |
cluster_master_promotion | Primary Failover | The HA standby was promoted to primary (failover event) |
cluster_backup | Backup Taken | An automated backup completed |
cluster_standby_create | Standby Created | An HA standby node was provisioned (initial setup or resize) |
Why You'd Look at This
- Audit. Did the cluster restart at 03:14 because of a maintenance run, or because of an underlying incident? The event timeline tells you.
- Postmortems. Cross-reference an outage with backup, resize, and failover events.
- Capacity planning. Look at the frequency of resizes to plan future tier upgrades.
- Failover verification. After a planned failover test, confirm
cluster_master_promotionappears in the timeline.
What's Not in the Timeline
- Per-user database operations (
DROP TABLE, query execution) — those live in the engine's logs. Use Log Forwarding to capture them. - Application-level connection counts — see the Insights tab.
- Replica-specific events — each replica has its own Events tab. Open the replica from the cluster list to see its history.
Replicas Have Their Own Timeline
Read replicas track their own events independently. Open the replica from the cluster list and check its Events tab.
Filtering & Searching
The current Events tab shows the full timeline without filters. For long-term retention, querying, and alerting on events, forward them via Log Forwarding to Datadog, OpenSearch, or another aggregator.
Frequently Asked Questions
How far back does the timeline go?
Several months by default — long enough for most postmortems. For longer retention forward events to your own observability platform.
Why don't I see a cluster_master_promotion event after a failover?
On HA clusters, failover happens transparently — by the time you check the timeline, the new primary is already promoted. Check the timestamps; the event card may have been the most recent on the day of the incident.
Can I get notified when an event happens?
Use Log Forwarding — alert on the relevant event in your destination (Datadog monitors, OpenSearch watchers, Papertrail alerts, etc.).