diff --git a/troubleshoot/observability/apm/processing-performance.md b/troubleshoot/observability/apm/processing-performance.md
index d78dde6576..0000c1f217 100644
--- a/troubleshoot/observability/apm/processing-performance.md
+++ b/troubleshoot/observability/apm/processing-performance.md
@@ -32,11 +32,11 @@ The results below include numbers for a synthetic workload. You can use the resu
| Profile / Cloud | AWS | Azure | GCP |
| --- | --- | --- | --- |
-| **1 GB**
(10 agents) | 15,000
events/second | 14,000
events/second | 17,000
events/second |
-| **4 GB**
(30 agents) | 29,000
events/second | 26,000
events/second | 35,000
events/second |
-| **8 GB**
(60 agents) | 50,000
events/second | 34,000
events/second | 48,000
events/second |
-| **16 GB**
(120 agents) | 96,000
events/second | 57,000
events/second | 90,000
events/second |
-| **32 GB**
(240 agents) | 133,000
events/second | 89,000
events/second | 143,000
events/second |
+| **1 GB**
(10 agents) | 19,000
events/second | 17,000
events/second | 18,000
events/second |
+| **4 GB**
(30 agents) | 33,000
events/second | 23,000
events/second | 25,000
events/second |
+| **8 GB**
(60 agents) | 52,000
events/second | 36,000
events/second | 48,000
events/second |
+| **16 GB**
(120 agents) | 74,000
events/second | 58,000
events/second | 71,000
events/second |
+| **32 GB**
(240 agents) | 127,000
events/second | 90,000
events/second | 133,000
events/second |
Don’t forget that the APM Server is stateless. Several instances running do not need to know about each other. This means that with a properly sized {{es}} instance, APM Server scales out linearly.