Rapids Events Are Kept After a Pod Is Replaced
The events endpoint now keeps the Pod events the platform has seen for seven days, so you can still read why a Pod was replaced or deleted.
What's changed
- GET /api/v1/serverless/{id}/events, and the serverless_events tool of the MCP server, now also returns the Pod events the platform observed for your container over the last seven days, merged with the live ones. Before, a replaced or deleted Pod took its events with it and the endpoint could show only the Pods that still existed.
- Events are collected by a health scan every five minutes, so a short-lived Pod or event can be missing, a single answer holds at most 500 events, and nothing from before this change is recovered. An empty list does not prove that nothing happened.
- The meta of the response now says whether live events (live_available) and retained events (retained_available, with retained_reason when they could not be read) were available, plus retention_days and sampling_interval_minutes. When the live events cannot be read, the retained ones are still returned.
- Only Pod events are retained; other platform events stay short-lived. The call still needs the serverless:diagnostics ability.