Document OOM Crashes

src/_posts/platform/app/2000-01-01-application-resources.md

@@ -0,0 +1,68 @@
+---
+title: Application Resources
+nav: Resources
+modified_at: 2026-05-05 00:00:00
+tags: app resources cpu memory ram swap storage oom
+index: 1
+---
+
+Application resources define the CPU, memory, swap, and storage available to
+each container running your application.
+
+## Container Sizing
+
+
+
+For the full list of available container sizes and their limits, see
+[Container Sizes][container-sizes].
+
+
+## CPU
+
+## Memory
+
+### RAM
+
+### Swap
+
+### Out of Memory Crashes
+
+When an application consumes all its allocated memory (RAM + swap), the system
+applies a protection mechanism called the **OOM Killer** (Out of Memory Killer).
+
+#### Sequence of events
+
+1. The application progressively uses all available RAM
+2. The system starts using swap space
+3. When memory and swap reach 100% usage, the OOM Killer intervenes
+4. The application is immediately terminated by the system
+
+#### Observable consequences
+
+* **Abrupt termination:** The application stops without a graceful shutdown process
+* **Automatic restart:** The container restarts according to its configuration
+* **Restart event:** A "Restart" event appears in the metrics timeline
+* **Data loss:** All non-persisted data in memory is lost
+
+#### Prevention and monitoring
+
+To avoid this scenario:
+
+* Regularly monitor memory charts in the [Metrics tab][metrics]
+* Set up [alerts][alerts] before reaching memory limits
+* Analyze usage spikes in correlation with deployment events
+* Consider upgrading to a larger [container size][container-sizes] if needed
+
+**Note:** The OOM Killer is a system protection mechanism. If your application regularly experiences OOM events, it typically indicates a need for code optimization or increased allocated resources.
+
+## Storage
+
+### Ephemeral Filesystem
+
+## Monitoring Resource Usage
+
+## Preventing Resource Exhaustion
+
+[alerts]: {% post_url platform/app/2000-01-01-alerts %}
+[container-sizes]: {% post_url platform/internals/2000-01-01-container-sizes %}
+[metrics]: {% post_url platform/app/2000-01-01-metrics %}

src/_posts/platform/app/2000-01-01-filesystem.md

@@ -2,7 +2,7 @@
 title: File System and File Storage
 modified_at: 2023-07-27 00:00:00
 tags: app runtime file system disk storage
-index: 1
+index: 2
 ---
 
 ## Introduction

src/_posts/platform/app/2000-01-01-metrics.md

@@ -1,7 +1,7 @@
 ---
 title: Application Metrics
 nav: Metrics
-modified_at: 2026-01-02 12:00:00
+modified_at: 2026-05-05 00:00:00
 tags: app metrics
 index: 35
 ---
@@ -23,17 +23,20 @@ The application chart displays global data that are not container specific:
 events and routing metrics.
 
 The **Requests per minute** chart show the number of requests the application
-receives per minute, the famous **RPM**. The number of server error responses generated by the application (HTTP responses in the 500 range) is displayed on the same chart as red bars.
+receives per minute, the famous **RPM**. The number of server error responses 
+generated by the application (HTTP responses in the 500 range) is displayed on 
+the same chart as red bars.
 
 **Note**: 504 and 503 errors can be generated by our reverse proxy. More
 information is available in the [routing documentation][routing-errors].
 
 On top of this chart, all the events that happened during the
-viewing period are displayed. This can help you link the application behaviour with events
-that happened on the platform, e.g. spot a deployment that contains a memory
-leak or follow your application behaviour after a scale operation.
+viewing period are displayed. This can help you link the application behaviour 
+with events that happened on the platform, e.g. spot a deployment that contains 
+a memory leak or follow your application behaviour after a scale operation.
 
-A lot of events are available on the application timeline but only a few relevant are displayed on the metrics view:
+A lot of events are available on the application timeline but only a few 
+relevant are displayed on the metrics view:
 
 - Restart event
 - Deploy event
@@ -61,10 +64,11 @@ The container charts use the container types defined in your [Procfile]({%
 post_url platform/app/2000-01-01-procfile %}).
 
 For each container type, two charts are shown. The first one shows the **CPU
-usage** and the second one the **memory** and **swap** usage of this type of
-container.
+usage** and the second one the **memory usage** and **swap usage** usage of this 
+type of container.
 
-The CPU chart may exceed 100% if the application uses more than one core of the CPU.
+The CPU chart may exceed 100% if the application uses more than one core of the 
+CPU.
 
 For the memory chart, the memory (in blue) and swap usage (in red)
 are stacked. That way the total memory usage of the application can be
@@ -94,35 +98,6 @@ platform/internals/2000-01-01-container-sizes %}).
 If the application has more than one container of a specific type, these charts
 show the mean CPU usage / memory consumption of all containers of the same type.
 
-## Behavior when memory and swap are fully consumed
-
-When an application consumes all its allocated memory (RAM + swap), the system applies a protection mechanism called the **OOM Killer** (Out of Memory Killer).
-
-### Sequence of events
-
-1. The application progressively uses all available RAM
-2. The system starts using swap space (visible in red on the memory chart)
-3. When memory and swap reach 100% usage, the OOM Killer intervenes
-4. The application is immediately terminated by the system
-
-### Observable consequences
-
-* **Abrupt termination:** The application stops without a graceful shutdown process
-* **Automatic restart:** The container restarts according its configuration
-* **Restart event:** A "Restart" event appears in the metrics timeline
-* **Data loss:** All non-persisted data in memory is lost
-
-### Prevention and monitoring
-
-To avoid this scenario:
-
-* Regularly monitor memory charts in the Metrics tab
-* Set up alerts before reaching memory limits
-* Analyse usage spikes in correlation with deployment events
-* Consider upgrading to a larger [container size](/platform/internals/container-sizes) if needed
-
-**Note:** The OOM Killer is a system protection mechanism. If your application regularly experiences OOM events, it typically indicates a need for code optimization or increased allocated resources.
-
 ## Detailed View
 
 If the application has more than one container of a type defined in its

src/_posts/platform/app/troubleshooting/2000-01-01-runtime-issues.md

@@ -25,7 +25,8 @@ The most common causes are:
 - Configuration issues
 - Bugs in your application code
 - Uncaught exception in your code (especially with non-compiled languages)
-- Insufficient resources
+- Insufficient resources, such as an Out of Memory (OOM) crash when the
+  application consumes all its allocated memory
 - Temporary error/unavailability of an external resource
 
 A Runtime Error can have several consequences, depending on the severity of the
@@ -112,5 +113,5 @@ when a Timeout Error occurs).
 
 You can modify this behavior by tweaking your
 [Notifier's configuration]({% post_url platform/app/2000-01-01-notifiers %}).
-The `app_crashed`, `app_crashed_repeated` and the `app_deploy` events can be
+The `app_crashed`, `app_crashed_repeated` and the `app_deployed` events can be
 particularly worth considering.

src/_posts/platform/internals/2000-01-01-container-sizes.md

@@ -1,83 +1,46 @@
 ---
 title: Container Sizes
-modified_at: 2015-12-02 00:00:00
-tags: internals containers sizes
+modified_at: 2026-05-05 00:00:00
+tags: containers sizes
 index: 2
 ---
 
 ## Comparative Table
 
-<div class="overflow-horizontal-content">
-	<table class="table">
-		<thead>
-		<tr>
-			<th>Name</th>
-			<th>Memory</th>
-			<th>CPU Priority</th>
-			<th>PID Limit</th>
-			<th>Price</th>
-		</tr>
-		</thead>
-		<tbody>
-		<tr>
-			<td>S - Small</td>
-			<td>256MB</td>
-			<td>Low</td>
-			<td>128</td>
-			<td>0.01€/h</td>
-		</tr>
-		<tr>
-			<td>M - Medium (Default)</td>
-			<td>512MB</td>
-			<td>Standard</td>
-			<td>256</td>
-			<td>0.02€/h</td>
-		</tr>
-		<tr>
-			<td>L - Large</td>
-			<td>1GB</td>
-			<td>Standard</td>
-			<td>512</td>
-			<td>0.04€/h</td>
-		</tr>
-		<tr>
-			<td>XL - eXtra Large</td>
-			<td>2GB</td>
-			<td>High</td>
-			<td>1024</td>
-			<td>0.08€/h</td>
-		</tr>
-		<tr>
-			<td>2XL - eXtra eXtra Large</td>
-			<td>4GB</td>
-			<td>High</td>
-			<td>2048</td>
-			<td>0.16€/h</td>
-		</tr>
-		</tbody>
-	</table>
+<div class="overflow-horizontal-content" markdown="1">
+| Name                       | Memory  | CPU Priority | PID Limit[^pid-limit] |
+| -------------------------- | ------- | ------------ | --------- |
+| S - Small                  | 256 MB  | Low          | 128       |
+| M - Medium (Default)       | 512 MB  | Standard     | 256       |
+| L - Large                  | 1 GB    | Standard     | 512       |
+| XL - eXtra Large           | 2 GB    | High         | 1024      |
+| 2XL - eXtra eXtra Large    | 4 GB    | High         | 2048      |
+{: .table }
 </div>
 
-Bigger container sizes are available upon request on the support.
-As a note, each new process requires a PID. And inside each process, each thread needs one too.
+Prices are available on the [Scalingo pricing page](https://scalingo.com/pricing).
+Bigger container sizes are available upon request on the support. 
 
-## Availability of the Sizes
-
-Our 30 days free trial only gives you access to small and medium containers, if you want
-to use another kind of size, please [fill your billing profile and payment
-method](https://dashboard.scalingo.com/billing).
+{% note %}
+Limits apply when using Scalingo under the free trial. For more information,
+see [what you can do under the free trial][free-trial-limits].
+{% endnote %}
 
 ## Container Limits
 
 Containers have various limits depending on their size. Here is a comprehensive list:
 
-- RAM: cf. above-mentioned table
-- Swap: twice the amount of RAM.
-- CPU access: all containers have access to all CPU cores. But higher priority
+- **Memory**: see the comparative table above.
+- **Swap**: twice the amount of RAM.
+- **CPU**: all containers have access to all CPU cores. But higher priority
   means twice as much priority compared to standard priority. For example,
   consider three containers, one has a high priority and two others have a
   standard priority. When processes in all three containers attempt to use
   100% of CPU, the first container would receive 50% of the total CPU time and
   the two others would receive 25%.
-- PID limits: from 128 (S) to 2048 (2XL).
-- Ulimit nofile: 1048576. Maximum number of files an application can open.
+- **PID limit**: see the comparative table above.
+- **Open file limit** (`nofile`): 1,048,576. This is the maximum number of files an application can open.
+
+[^pid-limit]: Each new process requires a PID.
+
+[free-trial-limits]: {% post_url platform/getting-started/2000-01-01-free-trial %}#what-can-i-do-under-the-free-trial