When you are oncall it’s common to have issues where due to a bug on your code your data or your system end up in a bad state that requires a human to change data ad-hoc. This is normally done by connecting to the database directly or running shell scripts altering the production env.

If your team main language have a REPL env, it may be a good idea to use it to fix production issues instead:

1. Your whole team is used to the language (and shell script or SQLs may not be so well known)
2. They can use production code with proper validation to avoid mistakes such as: making the data inconsistent, altering more items than they should
3. The code run at the REPL env may be used to fix the bug later on
4. If you can have a REPL similar to a jupyter notebook you may save the scripts and results in order to share the knowledge of (a) how to fix the issue and (b) what steps where taken to investigate the issue

Safety

Users should have a read-only account by default and only get write permissions with someone else’s approval and for single commands, basically a way of inforcing reviews of code that is run against production.