This specific error means that you ran out of memory inside the running thread (microflow). The server basically assignes a specific amount of memory to 1 thread and that is running out which is causing the error. If I remember correctly a standard environment has 254 threads and the amount of memory is divided by that amount. Thats why if you look at the graph itself it will look like you still have enough heapspace. 

Hey Brian,

I found two way how to figurate out locally what action is causing issue. 

First way is to open JConsole locally and trace all graphs while doing action in application. You will be able to see what action will use that 3.5-4 gb.(i forgot but by default your heap is 1/3 of ram or something like that)

Second way is top set your memory limit locally to 3.5gb again go through application until it's give you issue and stop application.

If you don't want to do following steps only thing that can pin point you what specific action break it is to get java heap dump and do analyst on it.

If you search in the Mendix Cloud logs by the error's message or some key words of the error's message that you know (java.lang.OutOfMemoryError) -- I think that after you find the logs you could expand upon the error details. You should be able to check the error stacktrace and the error message. In the stacktrace you may be able to see the affected microflow. 

Usually it's helpful to use the StartTransaction EndTransaction from community commons module in combination with batch processing mechanism so that after each processed batch in your microflows the memory is reset and not adding up.

See this reference for batch processing