ServiceNow only shows jvm memory at node level because everything running on that node shares the same Java heap. Your custom app, scheduled jobs, integrations, Flow Designer, and normal user transactions can all use the same memory at the same time.
A simple way to think about it is like one swimming pool. ServiceNow can tell you how much water is in the pool, but it does not label which part of the water was used by your scoped app.
You can still get a rough indication through stats.do. Open /stats.do and note which node you are connected to. Then look for the memory information, such as servlet memory, free memory, or allocated memory. The exact labels can vary depending on the instance.
For example, suppose the node shows 3000 MB in use before your scheduled job starts. While the job is running, it goes up to around 3800 MB. After the job finishes and garbage collection runs, it drops back to around 3100 MB.
That would suggest your job temporarily had a noticeable memory impact, but you cannot say that it used exactly 800 MB. Other transactions may also have used memory during that time, and garbage collection may have released memory while your job was running.
For a cleaner test, I would run the job in a quiet pdii or sub production instance, record the stats.do values before execution, check them while the job is running, and check them again afterwards. Also make sure you are comparing values from the same node, especially if the instance has multiple nodes.
So stats.do is useful for getting an indication of the memory impact, but it is not an exact memory profiler for one scoped application.
If you need exact memory profiling for a specific transaction, I would involve ServiceNow Support since that level of JVM profiling is not normally exposed to application developers.
If this helped, can you mark it as the solution or helpful?
