Curator 101: Troubleshooting 502 and 504 Errors

Matthew Orr
Curator Engineer
November 16, 2022

Quite simply, if you receive a 502 or 504 error while interacting with Curator, then the cause is a reverse proxy or load balancer sitting in front of Curator.  Curator, itself, does not generate these types of errors.

Because it’s annoying to type out “reverse proxy or load balancer” again and again, I’m going to refer to these as “upstream devices.”  Typically, you’ll either have one or the other type of upstream device.  Only in special circumstances will you have both types as two distinct devices, but the troubleshooting process is the same even if you do.

502 Errors

Just because your upstream device is responsible for showing you 502 errors, that doesn’t mean that everything is working correctly within Curator.  Sometimes, upstream devices show 502 errors when Curator encounters a different kind of error in an effort to be helpful.  The trouble is that the 502 error you get hides the actual error message that Curator was trying to convey.  It’s like your significant other spending several minutes on the phone with the doctor going through a seemingly serious diagnosis and treatment plan, and then you ask them what the doctor said, and their response is just, “They said something was wrong.  Don’t worry about the details.”

To find out what happened to Curator, you’ll either need a way to bypass the upstream device and follow the same steps that led you to the error, or you can check Curator’s logs to see if they show more detail.

If you are able to, navigate to the event log in Curator’s backend:  Backend > Settings > Event Log.  Look for errors that were logged around the same time you got the 502 error.  If this error message isn’t immediately obvious how to fix it, then reach out to your Curator support for help.

Sometimes the errors are severe enough that Curator’s backend isn’t accessible anymore.  In this case, you’ll need to retrieve the error logs directly from the server that houses Curator.  Curator’s error log can be found at <web root>/storage/logs/system.log where the web root is either C:\InterWorks\Curator\htdocs for Windows-based systems or /var/www/html for Linux-based systems.  Each entry in this log file should begin with a timestamp to aid with finding the logs around the time you encountered the 502, though this timestamp may be set to UTC instead of your own timezone so you may need to do some math.

Furthermore, sometimes the errors are severe enough that not even Curator is functioning well enough to log them out to its own error log.  In this case, you’ll need to view the underlying Apache HTTPD Web Server’s error log to find out what went wrong.  The logs can be found at C:\InterWorks\Curator\libs\Apache24\logs for Windows-based systems, and /var/log/httpd or /var/log/apache2 (depending on your flavor of Linux) for Linux-based systems.

504 Errors

Typically, this type of error is because the upstream device has a timeout set lower than Curator’s timeout.  By default, Curator’s timeout should be 300 seconds, though this may have been adjusted in your environment.  The fix is to ensure the upstream device’s timeout is set to at least as long as Curator, if not a little longer.  After all, it’s kind of rude to stop listening to someone while they are still thinking about what to say.