diff --git a/docs/src/SUMMARY.md b/docs/src/SUMMARY.md
index 9a386227bf111b82606dc1df27ac070be3cdc011..f65c9a61c9191704b48fa16b9377ea9850bb85b6 100644
--- a/docs/src/SUMMARY.md
+++ b/docs/src/SUMMARY.md
@@ -136,5 +136,6 @@
   - [Linux](./development/linux.md)
   - [Windows](./development/windows.md)
   - [Local Collaboration](./development/local-collaboration.md)
+  - [Using Debuggers](./development/debuggers.md)
 - [Release Process](./development/releases.md)
 - [Debugging Crashes](./development/debugging-crashes.md)
diff --git a/docs/src/development/debuggers.md b/docs/src/development/debuggers.md
new file mode 100644
index 0000000000000000000000000000000000000000..4de12f95256febe7dc84e26cd8336dd0cca7588e
--- /dev/null
+++ b/docs/src/development/debuggers.md
@@ -0,0 +1,112 @@
+# Using a debugger
+
+> **DISCLAIMER**: This is not documentation for the [planned debugger support in Zed](https://github.com/zed-industries/zed/issues/5065).
+> Rather, it is intended to provide information on how to use an external debugger while developing Zed itself to both Zed employees and external contributors.
+> Once debugger support is implemented, this section will be updated to provide information on how to use the built-in debugger as part of Zed development.
+
+## Build profile considerations
+
+By default, builds using the dev and release profiles (release is the profile used for production builds, i.e. nightly, preview, and stable) include limited debug info.
+
+This is done by setting the `profile.(release|dev).debug` field in the root `Cargo.toml` field to `"limited"`.
+
+The official documentation for the `debug` field can be found [here](https://doc.rust-lang.org/cargo/reference/profiles.html#debug).
+But the TLDR is that `"limited"` strips type and variable level debug info.
+
+In release builds, this is done to reduce the binary size, as type and variable level debug info is not required, and does not impact the usability of generated stack traces.
+
+In debug builds, this is done to reduce compilation (especially incremental compilation) time.
+
+However, while the type and variable level debug info is not required for good stack traces, it is very important for a good experience using debuggers,
+as without the type and variable level debug info, the debugger has no way to resolve local variables, inspect them, format them using pretty-printers, etc.
+
+Therefore, in order to use a debugger to it's fullest extent, you must compile a new Zed binary, with full debug info.
+
+The simplest way to do this, is to use the `--config` flag to override the `debug` field in the root `Cargo.toml` file when running `cargo run` or `cargo build` like so:
+
+```sh
+cargo run --config 'profile.dev.debug="full"'
+cargo build --config 'profile.dev.debug="full"'
+```
+
+> If you wish to avoid passing the `--config` flag on every invocation of `cargo`. You may also change the section in the [root `Cargo.toml`](https://github.com/zed-industries/zed/blob/main/Cargo.toml)
+>
+> from
+>
+> ```toml
+> [profile.dev]
+> debug = "limited"
+> ```
+>
+> to
+>
+> ```toml
+> [profile.dev]
+> debug = "full"
+> ```
+>
+> This will ensure all invocations of `cargo run` or `cargo build` will compile with full debug info.
+>
+> **WARNING:** Make sure to avoid committing these changes!
+
+## GDB/LLDB
+
+### Background
+
+When installing rust through rustup, (the recommended way to do so when developing Zed, see the documentation for getting started on your platform [here](../development.md))
+a few additional scripts are installed and put on your path to assist with debugging binaries compiled with rust.
+
+These are `rust-gdb` and `rust-lldb` respectively.
+
+You can read more information about these scripts and why they are useful [here](https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html) if you are interested.
+
+However, the summary is that they are simple shell scripts that wrap the standard `gdb` and `lldb` commands, injecting the relevant commands and flags to enable additional
+rust-specific features such as pretty-printers and type information.
+
+Therefore, in order to use `rust-gdb` or `rust-lldb`, you must have `gdb` or `lldb` installed on your system. If you don't have them installed, you will need to install them in a manner appropriate for your platform.
+
+According to the [previously linked article](https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html), "The minimum supported debugger versions are GDB 7.7 and LLDB 310. However, the general rule is: the newer the better." Therefore, it is recommended to install the latest version of `gdb` or `lldb` if possible.
+
+> **Note**: `rust-gdb` is not installed by default on Windows, as `gdb` support for windows is not very stable. It is recommended to use `lldb` with `rust-lldb` instead on Windows.
+
+If you are unfamiliar with `gdb` or `lldb`, you can learn more about them [here](https://www.gnu.org/software/gdb/) and [here](https://lldb.llvm.org/) respectively.
+
+### Usage with Zed
+
+#### Running Zed with a Debugger
+
+After following the steps above for including full debug info when compiling Zed,
+You can either run `rust-gdb` or `rust-lldb` on the compiled Zed binary after building it with `cargo build`, by running one of the following commands:
+
+```
+rust-gdb target/debug/zed
+rust-lldb target/debug/zed
+```
+
+Alternatively, you can attach to a running instance of Zed (such as an instance of Zed started using `cargo run`) by running one of the following commands:
+
+```
+rust-gdb -p <pid>
+rust-lldb -p <pid>
+```
+
+Where `<pid>` is the process ID of the Zed instance you want to attach to.
+
+To get the process ID of a running Zed instance, you can use your systems process management tools such as `Task Manager` on windows or `Activity Monitor` on MacOS.
+
+Alternatively, you can run the `ps aux | grep zed` command on MacOS and Linux or `Get-Process | Select-Object Id, ProcessName` in an instance of PowerShell on Windows.
+
+#### Debugging Panics and Crashes
+
+Debuggers can be an excellent tool for debugging the cause of panics and crashes in all programs, including Zed.
+
+By default, when a process that `gdb` or `lldb` is attached to hits an exception such as a panic, the debugger will automatically stop at the point of the panic and allow you to inspect the state of the program.
+
+Most likely, the point at which the debugger stops will be deep in the rust standard library panic or exception handling code, so you will need to navigate up the stack trace to find the actual cause of the panic.
+
+This can be accomplished using the `backtrace` command in combination with the `frame select` command in `lldb`, with similar commands available in `gdb`.
+
+Once the program is stopped, you will not be able to continue execution as you can before an exception is hit. However, you can jump around to different stack frames, and inspect the values of variables and expressions
+within each frame, which can be very useful in identifying the root cause of the crash.
+
+You can find additional information on debugging Zed crashes [here](./debugging-crashes.md).
diff --git a/docs/src/development/debugging-crashes.md b/docs/src/development/debugging-crashes.md
index 167623768103ff308e5a277d9964750c54c004b7..dddc13237783dbdc87ab807d9963ab10eb5063e4 100644
--- a/docs/src/development/debugging-crashes.md
+++ b/docs/src/development/debugging-crashes.md
@@ -30,3 +30,9 @@ The output contains the source file and line number, and the demangled symbol in
 When the app panics at the rust level, Zed creates a file in `~/Library/Logs/Zed` or `$XDG_DATA_HOME/logs` with the text of the panic, and a summary of the backtrace. On boot, if you have telemetry enabled, we upload these panics so we can keep track of them.
 
 A panic is also considered a crash, and so for most panics we get both the crash report and the panic.
+
+## Using a Debugger
+
+If you can reproduce the crash consistently, a debugger can be used to inspect the state of the program at the time of the crash, often providing very useful insights into the cause of the crash.
+
+You can read more about setting up and using a debugger with Zed, and specifically for debugging crashes [here](./debuggers.md#debugging-panics-and-crashes)