diff --git a/docs/merlin7/07-software-support/vscode.md b/docs/merlin7/07-software-support/vscode.md
index a79ce38..08afce7 100644
--- a/docs/merlin7/07-software-support/vscode.md
+++ b/docs/merlin7/07-software-support/vscode.md
@@ -146,5 +146,39 @@ interactive --status
 If it has ended, create a new allocation and regenerate the VS Code SSH config.
 
 ## VS Code via Open OnDemand
+
 <!-- Include open-ondemand-alternative information -->
 {% include-markdown "merlin7/07-software-support/includes/open-ondemand-alternative.md" %}
+
+## Tips and Other Suggestions
+
+### Limit Search Indexing
+
+VSCode will by default generate search indexes of your project directories. Depending on your local settings, or where VSCode is
+starting from, this could include many paths within the filesystem. Note that the Lustre filesystem used in Merlin7 is sensitive
+to file `stat` and similar IO, leading to congestion and noticeable delays from the filesystem. VSCode search can cause a overload of
+requests and negatively effect the responsiveness of the system (this effect can in extreme cases affect the entire cluster!).
+
+To limit this, please check and update the following settings as:
+
+```json
+  "search.exclude": {
+      "**/node_modules": true,
+      "**/.git": true,
+      "/data/**": true,
+      "/scratch/**": true,
+  },
+"files.watcherExclude": {
+      "**/node_modules/**": true,
+      "**/.git/**": true,
+      "/data/**": true,
+      "/scratch/**": true,
+},
+```
+
+Additionally, consider enabling the search "ignore files" feature, which will respect the files and paths as specified in `.*ignore` files.
+
+```json
+"search.useIgnoreFiles": true,
+"search.useGlobalIgnoreFiles": true,
+```
diff --git a/docs/news/posts/vscode-lag.md b/docs/news/posts/vscode-lag.md
new file mode 100644
index 0000000..ca1bd0a
--- /dev/null
+++ b/docs/news/posts/vscode-lag.md
@@ -0,0 +1,48 @@
+---
+date:
+  created: 2026-07-30
+tags:
+  - software
+  - support
+---
+
+# VSCode and system congestion
+
+Over the past few months we've seen a large surge in the number of users using
+VSCode (via the Remote SSH extension). The extension causes a persistent
+service, called the VSCode Server, to be launched on the remote system, in
+order to fulfill and extend VSCode's features to the remote system.
+
+## What's the problem?
+
+Wether intentionally or not, many users' VSCode sessions launch on the login nodes
+(i.e. `login001` and `login002`) and are left to idle long after the user has
+"disconnected" from the cluster. This can cause several problems which eventually
+lead to slow responsiveness of the login node:
+
+- linger processes (at least 20 per user session) are left behind, consuming resources
+- the Lustre filesystem struggles to handle the increasing file system operations (e.g. `statfs`, `getattr`, etc.)
+- other processes stall waiting for the filesystem to respond; either they continue to hang or eventually fail
+- all interactive sessions (i.e. other logged in user sessions) become laggy and eventually totally unresponsive
+
+Note that these issues happen even when the system is not under load!
+
+The causes for these issues from the VSCode Server service are:
+
+- timer based behaviours, like file indexing and connection checks, keep triggering regardless of user activity
+- the process often maintains state within memory, meaning resources are consumed regardless of user actions (e.g. doing something interactive or logged out)
+
+## How do we prevent this situation from happening?
+
+The VSCode developers have [invested hardly any
+effort](https://github.com/microsoft/vscode-remote-release/issues/10875) in
+providing mechanisms that SysAdmins can use to regulate VSCode Server on the
+remote machines. Intervention by our users is needed.
+
+Within out [documentation for VSCode](../../merlin7/07-software-support/vscode.md) we provide a guide to
+use SLURM interactive sessions, using compute nodes to host the VSCode Server service, and also Tips
+on improving the "performance" of VSCode by limiting filesystem operations. We ask all users to read
+through the documentation and adapt their workflows to help improve the usability of the cluster.
+
+If these system congestion issues keep happening, we might be forced to take more drastic actions, including
+fully banning the use of VSCode Server on Merlin7.