# Monitoring

The instance dashboard, the metrics groups and log filters in SurrealDB Studio, and how they relate to the full observability surface.

Every instance reports its own resource use and activity, with no agent to install and no scrape target to configure.

The at-a-glance view is the instance **Dashboard**. The detail is under **Metrics & logs** in the instance sidebar of [SurrealDB Studio](https://app.surrealdb.com).

## The instance dashboard

Opening an instance lands on its dashboard, which states what the instance is and what it is currently doing. The header reports the version, region, instance type, and organisation.

![The dashboard for the api-production instance in SurrealDB Studio, showing it running SurrealDB 3.2.4 in aws-euw1 on the Free type in the Acme Corp organisation, with cards for 512 MB memory, 0.25 vCPUs of single-node compute, 21.64 MB of 1 GB storage used, and version v3.2.4, above Activity charts plotting memory usage, compute usage, and network ingress and egress over the last hour.](~/assets/img/surrealdb/manage/instance-dashboard.webp)

The four cards across the top are the numbers to check first. **Storage** is the one to watch over time. It shows consumption against the provisioned limit, and a disk that reaches its limit stops accepting writes. See [Scaling](/docs/manage/instances/scaling.md) for raising it.

Below the cards, **Activity** plots resource use over a period you select. The default is one hour. Longer windows show trends rather than spikes.

## Metrics

**Metrics & logs** groups the signals into three.

| Group | What it reports |
| --- | --- |
| **System** | Compute and memory use of the instance |
| **Connections** | HTTP and RPC request volume |
| **Network traffic** | Network ingress and egress |

Each group takes a time range: the last hour, twelve hours, day, week, or month. Short ranges show what is happening now. Longer ranges are what you need before you decide to resize, because a resize should answer a trend rather than a single spike.

Read the groups together rather than separately. Rising connection counts with flat compute point at connection handling in the application. Rising compute with flat connections points at the queries themselves.

## Logs

The **Logs** view lists instance activity: startups and shutdowns, imports, version changes, and other lifecycle events. Filters narrow the list by:

- **Level:** the severity of the entry.
- **Source:** the component that emitted it.
- **Message:** free text within the entry.

Log entries stay queryable for a retention period. To keep them longer, ship them to your own log store rather than rely on the console view. That is what compliance requirements and correlation with other systems usually need.

> [!NOTE]
> These are activity logs for instance-level events. Audit logs, which record who ran which statement against which resource, are not yet available for instances. The record shape and the pipeline are documented under [audit logging](/docs/manage/observability/audit-logging.md) for deployments that have them.

## What to watch

These signals most often warrant action:

- **Storage** climbing towards the provisioned limit.
- **Compute or memory** sustained near the instance-type ceiling under ordinary traffic.
- **Connection counts** saturating, or clients being refused.
- **Error-rate spikes** in the logs that correlate with a deployment or a schema change.

Sustained pressure on the first three is a [scaling](/docs/manage/instances/scaling.md) signal. A spike that coincides with a change you made is usually a query or schema problem, and a resize hides it rather than fixes it.

## From the command line

`surrealctl instance metrics` and `surrealctl instance logs` print the same data for scripting or for feeding an external monitor. `surrealctl instance watch` follows the state of an instance during a change. See [surrealctl instances](/docs/manage/surrealctl/instances.md).

## The wider observability surface

This view presents the same telemetry a self-hosted deployment scrapes directly. When you need the full vocabulary, see the [Observability](/docs/manage/observability.md) section, and the [metrics reference](/docs/manage/observability/metrics.md) in particular. Those pages cover every metric family and label, the environment variables that control them, the audit-log record shape, and the slow-query pipeline.