diff --git a/docs/news/posts/vscode-lag.md b/docs/news/posts/vscode-lag.md
index ca1bd0a..2753752 100644
--- a/docs/news/posts/vscode-lag.md
+++ b/docs/news/posts/vscode-lag.md
@@ -11,21 +11,24 @@ tags:
 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.
+order to fulfill and extend VSCode's features to the remote system. Orindarily, this
+is fine, but since the start of the year, we've see a growing number of incidents
+affecting the reliability and performance of the login nodes.
 
 ## 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:
+lead to performance degradation incident on the login node(s), marked by slow responsiveness
+and laggy behaviour:
 
 - 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!
+**Note that these issues happen even when the system is not under load!**
 
 The causes for these issues from the VSCode Server service are: