AW Gamelift takes 5 minutes to detect crash and mark the session as terminated

In addition to the rePost Agent's answer:

While the previous answer correctly identifies the need for ProcessEnding(), it is important to clarify that this only works for graceful exits. If the process crashes (e.g., segmentation fault), this call is never reached.

To minimize the 3-minute health check window, consider these two approaches:

1. Catching Unexpected Exits: If you are running on Linux, implement a signal handler to catch SIGSEGV or SIGTERM. Inside the handler, call ProcessEnding() before exiting the process. This turns a hard crash into an "orderly" termination, allowing GameLift to clear the session immediately.

2. Decouple Matchmaking from GameLift Status: Relying solely on GameLift's session status to block matchmaking is a known architectural bottleneck. Implement a 'Client-Side Heartbeat' or 'Server-Side Health Ping' in your own matchmaker service. If the server is unreachable for 10–20 seconds, your service should proactively mark the session as 'Dead' and release the players, rather than waiting for the 3-minute GameLift health check cycle.

see also: https://docs.aws.amazon.com/gameliftservers/latest/developerguide/gamelift-sdk-server-api.html#gamelift-sdk-server-api-processending

In sum: The 3-minute delay is a built-in safety feature of the health check logic. Reducing it significantly requires either proactive signal handling or an autonomous matchmaker.

To reduce the time it takes for Amazon GameLift to detect and mark a crashed session as terminated, you should ensure your game server is properly integrated with the Amazon GameLift Server SDK and implements proper shutdown handling.

The key is to call the ProcessEnding operation from the Server SDK in all paths where your server could exit, including crash scenarios. This notifies Amazon GameLift that the game session is ending, which triggers an immediate status change to TERMINATED and allows the service to quickly replace the server process with a new one.

Here are some important considerations:

Implement proper termination handling:

• Call ProcessEnding on the Amazon GameLift Server SDK in all exit paths to ensure the session is properly cleaned up and immediately replaced
• Don't reuse server processes for multiple sessions - after a session ends, call ProcessEnding and exit to trigger immediate creation of a new process

Add backup termination mechanisms:

• Implement a backup process termination mechanism for cases where a game session is placed on the server but players never connect or get disconnected unexpectedly
• This ensures the process ends correctly in these situations and is replaced with a fresh server

Health monitoring:

• Implement a robust OnHealthCheck callback that accurately reports the health status of your game server
• This allows Amazon GameLift to detect unhealthy processes more quickly

By properly implementing these SDK calls and callbacks, you can significantly reduce the detection time for crashed sessions, allowing your players to re-enter matchmaking much faster than the current 4-minute delay you're experiencing.
Sources
Development phase steps for successful launches on Amazon GameLift Servers | AWS for Games Blog

Add Amazon GameLift Servers to your game server with the server SDK - Amazon GameLift Servers

Complete the health evaluation and respond to the callback within 60 seconds. If Amazon GameLift Servers doesn't receive a response in that time, it automatically considers the server process to be unhealthy.

If a server process continues to report as unhealthy or doesn't respond for three consecutive health checks, then the service might shut down the process and start a new one. The service collects metrics on a fleet's server process health.

The health check interval—three attempts at 60-second intervals, totaling approximately three minutes—serves as the baseline timeframe for GameLift to determine that a process is "unhealthy." When the time required for subsequent cleanup operations (such as uploading logs to S3 and updating status) is added to this, the total duration approaches the perceived four-minute mark.

Solution 1: Actively use the GameLift Server SDK 5.x TerminateGameSession API

You can use the TerminateGameSession API (or terminate-game-session in the CLI), which was introduced in SDK version 5.x and later. This API allows you to explicitly terminate a game session from an external source (such as your backend) without waiting for GameLift's internal detection mechanisms.

TRIGGER_ON_PROCESS_TERMINATE: Calls OnProcessTerminate() on the server process to initiate a standard shutdown sequence. FORCE_TERMINATE: Immediately stops the process without waiting for the standard shutdown sequence.

By using this, you can force the session status to TERMINATED the moment your backend detects a crash, bypassing the need to wait for GameLift's health check cycle.

Solution 2: Implement custom crash detection to speed up detection

By combining your own detection methods with GameLift's health check cycle, you can detect crashes significantly faster than the standard four-minute window.

• Player-side heartbeat/connection monitoring: Configure the game client to periodically send "keep-alive" signals to your backend; if these signals cease for a certain period, treat that player's session as "dead." Since this mechanism operates independently of GameLift's status reporting, it offers the fastest and most reliable detection.
• Watchdog process on the instance: Run a lightweight monitoring process alongside the game server to monitor child processes at the OS level. This process can instantly detect crashes (abnormal terminations or signal-based exits) via OS events and immediately call TerminateGameSession with the FORCE_TERMINATE option.

The most effective approach is a combination of Method 1 (actively calling the TerminateGameSession API) and a custom heartbeat monitoring system. Instead of waiting for GameLift's internal health check cycle, you can use the API to force termination the moment your monitoring system detects a crash, thereby reducing the wait time from four minutes to just a few seconds or tens of seconds.