Thanks — I’m responding to your question about whether shutdown callbacks still run when an entrypoint or agent hits an internal server error, and what you can do to track metrics if they don’t. Short answer • The documentation confirms that shutdown callbacks registered with

ctx.add_shutdown_callback()

run when a session ends and during normal post-processing/cleanup, and that the framework will wait up to 10 seconds for callbacks before forcefully terminating. • The docs do not confirm that shutdown callbacks are guaranteed to run if an unhandled internal server error crashes the entrypoint or agent. • There is no documented alternate crash-hook guaranteed to run on an unhandled internal server error. What that means for you • You cannot rely on shutdown callbacks as a guaranteed way to capture metrics after an unhandled internal server error. • For reliable metric collection on crashes, you should add explicit error handling and external reporting that does not depend solely on the shutdown callback lifecycle. Recommended approaches you can implement now • Wrap entrypoint/agent top-level logic with try/except (or equivalent) and report metrics from the exception handler. a. Catch exceptions at the highest possible boundary in your entrypoint or agent. b. In the exception handler, send metrics/logs to your external monitoring (e.g., Prometheus pushgateway, StatsD, Datadog, or a logging sink). c. Re-raise or exit after reporting if needed. • Use a small, fast, synchronous reporting path in the exception handler so reporting is more likely to complete before process termination. • If your runtime supports it, register a process-level uncaught-exception handler (for example, top-level exception hook) that reports errors similarly. • Emit periodic heartbeats or health-check metrics from a separate supervisor process so crashes are detectable even if the crashing process cannot report on shutdown. • Configure your infrastructure to capture process exit codes, core dumps, or last logs (for example, container logging + centralized log aggregation) so you can reconstruct crash events. Questions to narrow recommendations • Which language/runtime are you using for your entrypoint/agent (Python, Node, Go, etc.)? • Are you running agents in containers/k8s or on bare VMs? • Do you already use a monitoring system (Datadog, Prometheus, CloudWatch, etc.) you want to integrate with? If you share the runtime and deployment setup, I’ll give a concise code example and a recommended reporting pattern tailored to that environment. Sources: Job lifecycle | LiveKit Documentation | SIP Lifecycle Management Agent | LiveKit Documentation, with interactive elements