Glitch boot failure diagnosis when console logs are truncated

Short answer

There is no documented, guaranteed retention limit for Glitch boot logs, and the project console cannot reliably diagnose failures that occur before your application process starts. During repeated crash loops, the console usually shows only the tail of the most recent attempt, if anything, because the log buffer is ephemeral and is discarded when a new container is created after a sleep/wake cycle.

What is established vs. what is likely

The console captures stdout and stderr from the application process once it is running. It does not reliably expose platform orchestration, container initialization, or build/install output. A cold start creates a new container with a fresh buffer, so earlier boot output is lost. The likely reason logs appear truncated is that the platform prioritizes liveness over preservation: a fast crash-and-restart cycle can overwrite the buffer before it is read.

Do not assume a specific byte or line cap. The lack of a documented retention policy is itself evidence that no guarantee exists.

Steps for this case

1. Do not rely on the console for boot forensics. Design your diagnostics assuming console output during startup is lost.
2. Write a durable heartbeat as the first action in your start script. Send a timestamped record to an external store before any other initialization. If that record never arrives, the failure is almost certainly upstream of your application code.
3. Deploy a minimal test app. Have it emit a single line to an external endpoint immediately on start. If the endpoint receives nothing during a failed boot, the process is not being reached.
4. Force a cold start and observe. Let the project sleep, wake it, and note whether any pre-application output ever appears in the console.

The missing detail that changes the advice

The one diagnostic detail that would change this recommendation is whether your application process ever reaches its first log statement. If it does, investigate application startup errors. If it never does, the failure is in the platform build/install phase or container orchestration, and the project console will not help—platform-side support is required.

Assumptions and verification

This guidance assumes a free-tier project with default sleep behavior. Paid tiers or recent platform changes may differ. Because Glitch's logging pipeline can change without notice, check current help or status resources for any documented retention policy, and treat the absence of documentation as confirmation that no guarantee exists.

For example, a Node.js start script might begin with an external call like this:

// Illustrative only — adapt to your runtime and log store
const t0 = Date.now();
sendToExternalLog({ event: 'boot-start', t: t0 });
// ... then continue with normal startup