The 502 error should only be shown if your application can't be reached, which if you didn't shut it down at that time it could be that your application is becoming unresponsive at certain moments.
This can have various causes. I'd recommend starting by reviewing your monitoring information. If you don't know the exact time the users started experiencing the issues the error message you were referring to is a good start.
Start by finding that time on the graph and scan down through all graphs and identify if there are spikes in any if the graphs within 1 hour before and after your chosen time. Depending type of graph that has the spike you should take different actions. For example if you only see a cpu spike in the app node there is likely X nr of microflows consuming all resources (X >= nr of CPUs), a spike on db node CPU indicates to many complicated queries, a spike in memory on app node indicates to many objects in memory.
To re-iterate, identifying all spikes at that problem time is most important to find the cause of your issue.
(Please note my examples on reading the report are overly simplified, and you need to look at the combination of graphs to draw a conclusion, a single graph can never indicate the root cause of your problem)
In my case, the 502 error was caused by the Application Request Routing feature of IIS. The Mendix application log didn't show any errors, but the IIS log did:
> 2017-03-02 09:11:09 10.77.26.87 POST /ws/<SomeWebService>/ X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=e81c7817-3ee8-4521-90f4-e77bc59480cf 80 - <IP address> Mono+Web+Services+Client+Protocol+4.0.50524.0 - 502 3 12002 120019