diff --git a/labs-and-projects/Lab1/vm/README.md b/labs-and-projects/Lab1/vm/README.md
index 76e16ae2e94ba5eac5e200bf9e9e6b88c5a40a26..f3df1a9c58719c2f7063ef3d14984a494bc092fd 100644
--- a/labs-and-projects/Lab1/vm/README.md
+++ b/labs-and-projects/Lab1/vm/README.md
@@ -34,3 +34,51 @@ Backup option (future directions if you even run out of GCP credits - not needed
 [Azure Directions](azure/README.md).  At the time these directions
 were written, Microsoft offers students $100/year of credit per year.
 These directions might be a bit stale.
+
+# **Note:** How to Stop and Start your VM
+
+**Important: Before you begin this process, make sure to save all your progress by pushing it to your Git repository. If you are unsure how to do this, refer to the [git-workflows](../../git-workflows/README.md) document for guidance.**
+
+Throughout the semester, you might run out of RAM on your VM. RAM (Random Access Memory) is different from the persistent storage (disk space) on your VM, which is much larger. RAM is the memory used to run programs and handle active processes on your VM, while storage is where files and data are saved permanently.
+
+Running out of RAM can happen for multiple reasons, such as running large programs or running them for extended periods, as they can accumulate data in memory. In our case, the most common reason for running out of RAM is Jupyter Notebook. While it is constantly running to maintain the SSH tunnel to your browser, it accumulates a large amount of metadata, which can consume significant memory over time.
+
+To check how much memory (RAM) you have left on your VM, run the command `htop` in the terminal. You will see an output similar to this:  
+<img src="img/htop.png"/>
+At the top, look for the bar labeled **"Mem"**. If you notice this bar is nearly full, it might be a good time to stop and restart your VM. In the example above, the memory usage is almost at its limit.
+
+**Note:** Stopping your VM will terminate all processes running on it. If you have active processes, stopping the VM could result in data loss or corruption. **Make sure to save your work before proceeding.**
+
+## Steps to Stop and Resume Your VM
+
+1. Open your browser and go to **Google Cloud > Console > Compute Engine > VM Instances**.
+2. Locate your VM under "VM Instances."
+<img src="img/vm.png"/>
+3. Click on the three vertical dots next to your VM.
+<img src="img/options.png"/>
+4. Select **"Stop"** from the dropdown menu.
+5. You will see a warning about potential data loss. Confirm by clicking **"Stop"** again.
+
+Wait a few minutes for your VM to shut down. You can monitor its status under the "Status" column. Once it shows **Stopped**:
+
+6. Click on the three vertical dots again and select **"Start/Resume."**  
+<img src="img/options.png"/>
+
+**Note:** After restarting, your VM will have a new external IP address. You will need this updated IP to SSH into your VM.
+
+## Reconnecting and Restarting JupyterLab
+
+Once your VM is running again:
+
+1. SSH into your VM using the new external IP.
+2. Run the following commands to restart JupyterLab:
+
+```bash
+python3 -m jupyterlab password
+```
+
+```bash
+nohup python3 -m jupyterlab --no-browser --ip=0.0.0.0 --port=2020 &
+```
+
+3. Open your browser and use the new IP address to access JupyterLab.
diff --git a/labs-and-projects/Lab1/vm/img/htop.png b/labs-and-projects/Lab1/vm/img/htop.png
new file mode 100644
index 0000000000000000000000000000000000000000..f119e4f2b7c752c926c9a9e7378281db0abe636f
Binary files /dev/null and b/labs-and-projects/Lab1/vm/img/htop.png differ