The below metrics can be monitored for your instances from the Aura Console:

• CPU Usage
• Storage Used
• Heap Usage (%) (Metric available only in Enterprise instances)
• Out Of Memory Errors
• Garbage Collection Time
• Page Cache Evictions

All the metrics have tooltips in them with explanations about the metric.

CPU Usage:

The Neo4j Aura Cloud Service graph database is architected to provide 24x7 availability. Behind the scenes, Neo4j Aura runs a 3-node Causal Cluster graph database. Each aura node runs in its own container.

Therefore, when viewing the Aura database METRICS page, it shows the AVERAGE CPU Usage (%) for the 3 Causal Cluster nodes. Note that most access patterns will translate to the 3 database nodes having similar CPU usage.  

Storage Used

Aura instances are sized to have some additional disk space compared to the allocated memory to allow loading large data dumps.

The Neo4j Aura team monitors actual disk usage and has alarms set for certain thresholds.  When necessary, the Neo4j Aura team will send alerts to customers who are about to use up all their database storage capacity.

Heap Usage (%)

Note: This metric is available only in Enterprise instances.

This chart shows how much Java Virtual Machine (JVM) memory is used to calculate responses to your queries. Normal JVM heap management involves fluctuations, and high levels are to be expected.

At rest (database idle), it will display a classic saw tooth pattern, and this is expected.

The sawtooth pattern occurs because the JVM constantly allocates memory on the heap when new objects are created during normal program execution.
However, many of these objects have short lifetimes and are quickly eligible for collection by the garbage collector. As the garbage collector completes its tasks, a decline in the memory usage graph becomes visible.

Garbage collection kicks in only when the heap memory is almost full. And during the garbage collection process, objects that are no longer in use are cleared, thus making space for new objects.
Hence the heap memory doesn't automatically get cleared when corresponding operations are completed. So the 80% mark is common and not necessarily an issue.

Neo4j databases run on the Java platform, making memory usage more complex to understand. 
This isn't just a Neo4j thing and is applicable to most applications running on Java.
We suggest reading the article, Understanding memory consumption, which includes explanations of Operating System memory usage and Java Virtual Machine (JVM) memory usage.

Out Of Memory Errors

The above error is thrown when the JVM cannot allocate memory for an object, and no more memory can be made available by the garbage collector.

Most often, there are 2 methods to solve this problem:

1. Use a larger AuraDB instance size. (use the resize function on the Aura Console)
2. Put less workload on the AuraDB.

Garbage Collection Time

Objects in Java are allocated in heap memory inside the JVM. Java’s garbage collector will go through the heap and mark objects that are in use by the JVM.  Later, the garbage collector reclaims unmarked memory.

When Garbage Collection takes too long, that means the JVM memory size of AuraDB is not big enough to cope with the current workload, and the database's performance will degrade.

Page Cache Evictions

This chart displays the number of times data in memory is being replaced. A spike can mean your workload is exceeding the database's available OS memory, and you may notice a degradation in performance or query execution errors. Consider resizing your instance upward to improve performance if this metric remains high.