There are a few different code environments in Quest. College folks should be on the newer code base (sometimes refereed to as beta, or q-web 6, q-web 7, or both qweb6,7), high school folks may be on the older code base (qweb 3, or 4)
While Quest is messy and does not have the team to have clearly vetted forward thinking green lights to prevent all sorts of problems for the end users, it does have the backup server where Steve-the-developer uses as his playground to unroll the latest and greatest. Whenever anything isn't working on the environment you're on, go to this updated nightly environment and see if the problem is resolved there.
To get to this narnia-eque place, change 'quest' in the URL to 'lbtest' (which stands for load balancer test)
ex:
https://lbtest.cns.utexas.edu/instructor/
If too deep in to something specific, an error will be thrown, so best to do at the beginning of a going down a rabbit hole if at all possible (eg instructor/student/inst admin/sys admin start).
Before a code push, it's also important that we are on lbtest heavily to try to preemptively catch anything that isn't working before it gets rolled into the environment for the masses. If you find any errors on lbtest, let Leta know or trac it immediately. If an error exists on quest (beta) but not lbtest, the issue has already been resolved and will be rolled out next push or hotfix–if it's urgent for the client feel free to direct them to the specific lbtest site with information pertinent to them. Generally we try to keep the curtain on lbtest somewhat closed to not expose the mess, but sometimes it's understandable to give someone a peek to help them get what they need in a timely fashion. Some UT profs are well versed at flipping between prod and lbtest; I just offer a disclaimer that it's our sandbox where things get fixed, so they might find other things that don't work as expected there–best to just dip in for a specific purpose and then go back to the common quest environment.