Why losing the end of a program’s telemetry hurts more than losing any other part.

When engineers investigate a problem, they usually care most about what happened just before something went wrong. A service that crashes leaves its most important clues in the final moments: the request that triggered the failure, the error that was raised, the metrics that spiked, and the log lines that explained the state of the system. These are exactly the pieces of telemetry that are youngest, and therefore most likely to still be sitting in a memory buffer when the process ends.

This creates a cruel irony. The telemetry system is designed to help you understand failures, but it is most fragile at the very moment a failure happens. A process that is killed, crashes, or simply finishes quickly may never get the chance to send its newest data. The dashboards then show a calm, clean picture right up to the moment the system died, and the cause of death is missing from the record.

It is not only about crashes

It would be easy to assume that shutdown problems only matter during rare disasters. In reality, processes end constantly in healthy systems. Every deployment replaces running instances. Every scale-down event removes machines. Every scheduled job finishes and exits. Every serverless function is frozen after returning a response. In a busy organisation with automated deployments, instances are ending many times a day, and each ending is an opportunity to lose a little telemetry.

Who actually feels the loss

The people affected by missing end-of-life telemetry are rarely the ones who caused it. On-call engineers feel it first, because they open a trace during an incident and find that the request they need is not there. They lose precious minutes wondering whether the tracing system is broken, whether the request was sampled out, or whether the service really did nothing. Each of those doubts is a direct result of a small technical omission made months earlier by someone who was never on call that night.

Product and business teams feel it more quietly. They read dashboards that undercount activity around every release, and they may draw the wrong conclusions about traffic, conversion, or error rates. Capacity planners feel it when totals are slightly lower than reality. Finance and compliance teams feel it when usage-based metrics, such as the number of processed jobs, disagree with other records. In every case, the cost is a gradual erosion of trust in the data, and trust in observability data is much harder to rebuild than to protect.

An asynchronous pipeline with several waiting rooms.

To understand why shutdown matters, you first need a picture of what happens between the moment your code records something and the moment it reaches a backend. OpenTelemetry deliberately keeps this path off your critical path. Recording a span or a measurement must be fast, so the SDK does the cheap work immediately and defers the expensive work, such as network calls, to background threads or timers.

flowchart LR
  A["Application code records telemetry"] --> B["SDK creates span, metric, or log record"]
  B --> C["Processor or reader holds it in memory"]
  C --> D["Timer or size limit triggers a batch"]
  D --> E["Exporter sends the batch over the network"]
  E --> F["Collector or backend receives it"]
        

The waiting room is the risk

Step three in the picture, where data sits in memory waiting for a batch to be triggered, is where all the danger lives. Anything in that waiting room is invisible to the outside world. It cannot be seen by the backend, it cannot be recovered by anyone else, and it exists only in the memory of a process that may be about to disappear.

How long data waits, and why the numbers matter.

Batching is the technique that makes telemetry affordable. Sending one network request per span would overwhelm both the application and the network, so SDKs gather items and send them in groups. The standard batch processors for traces and logs send a group when either a time limit passes or a size limit is reached, whichever comes first. Metrics work differently. A periodic reader collects and sends the aggregated values at a fixed interval.

What those defaults mean in practice

With a five second schedule delay, a process that is killed at a random moment will, on average, have about two and a half seconds of spans and log records that were never sent, and up to five seconds in the worst case. With a sixty second metric interval, the same process will on average lose about thirty seconds of aggregated measurements, and up to a full minute in the worst case. These are not bugs. They are the intended trade-off that makes batching cheap.

Why not simply send everything immediately

Some teams react to data loss by shortening the delay to almost nothing. That reduces the waiting room, but it multiplies network calls, increases CPU use for serialising tiny batches, and puts more load on Collectors. It can also hurt the application itself on busy systems. A better answer is to keep sensible batching and make sure the waiting room is emptied properly whenever the process ends.

Queue overflow: the other way to lose data

Abrupt exits are not the only way for items to disappear from the waiting room. The queue has a fixed size, and when it is full, new items are dropped rather than slowing the application down. This is a deliberate protection, because telemetry must never be allowed to stall the business logic. But it means that during a burst of activity, or while the exporter is struggling to reach a slow Collector, items can be lost long before any shutdown happens.

This matters for shutdown because a flush can only send what the queue still holds. If the queue overflowed a minute earlier, the final flush will deliver a clean, complete-looking batch that is missing a chunk of earlier data. Watching the drop counters of your processors, and sizing queues and batch sizes for your peak traffic rather than your average, is therefore part of the same discipline as shutting down properly.

A realistic estimate of the damage across a fleet.

Let us put numbers to the problem. Suppose a service runs on fifty instances, and each instance records about two hundred spans per second. The batch processor sends data every five seconds. At any moment, each instance holds roughly the last five seconds of spans in its queue, which is about a thousand spans. That is comfortably under the default queue size, so nothing has been dropped yet, but all thousand are waiting.

During a rolling deployment, all fifty instances are stopped and replaced, one after another. If each one is stopped abruptly, up to a thousand spans disappear from each, giving a worst-case loss of fifty thousand spans in a single deployment. A team that deploys ten times a day could lose half a million spans daily, always from the end of each instance’s life, and nobody would see an alert.

The metric side of the story

Metrics lose data differently. A metric data point summarises everything that happened in an interval. If an instance exits thirty seconds into a sixty second interval, the half interval of increments is lost. With cumulative reporting, the next instance starts a new series from zero, and the lost half minute simply never appears in any total. With delta reporting, the lost interval is a permanent hole in the sum, because delta data points are never repaired by later reports.

The cost is invisible but real

These losses distort the picture in subtle ways. Request counts around deployment times dip slightly, and graphs show small valleys exactly when new versions roll out, which can be mistaken for real changes in traffic. Error spans from instances that were struggling just before they were replaced never appear, so a problem that caused the replacement is hidden. Traces of long requests that were in flight when the instance stopped look incomplete or absent.

Why the missing data is biased towards trouble

The loss is not spread evenly across time. Instances are often replaced precisely because something was wrong with them: they were slow, they ran out of memory, or they started failing health checks. That means the final seconds of an instance’s life are disproportionately full of errors and slow requests. Imagine an instance that normally returns errors for one percent of requests, but in its final five seconds before an automatic restart, the error rate climbs to forty percent. If those final thousand spans are lost, the surviving data shows an instance that looked mostly healthy.

This produces a quiet optimism bias. The error rate you see in your dashboards is lower than the real error rate, because the failing moments are the ones that disappear. The effect is small for any single instance, but across a fleet that restarts regularly, it can hide real instability for a long time. Fixing shutdown does not only recover missing counts. It removes a systematic tendency for your data to look better than your system really is.

They sound similar, but they do different jobs and are used at different times.

The OpenTelemetry SDK specification gives each provider two related operations. The first is usually called force flush, and the second is called shutdown. People often use the words interchangeably, which leads to bugs. Understanding the difference is one of the most useful things you can learn about the SDK lifecycle.

Both are bounded by time

Both operations are meant to finish or give up within a limited time. A network that is slow or a backend that is down must not be allowed to freeze the application indefinitely. The specification therefore expects these calls to complete, fail, or time out in a reasonable period, and many SDKs accept an explicit timeout so that you can choose your own limit.

The orderly sequence that turns a running pipeline into a quiet, empty one.

Shutdown is not a single action. It is a chain of steps passed down from the provider to its processors, and from the processors to the exporters. Each layer is responsible for finishing its own work and then telling the layer below it to do the same. When the chain completes, nothing is left in memory and no background work is running.

What shutdown cannot do

Shutdown can only send what exists. It cannot send spans that have not ended yet, because unfinished spans are not complete records. It cannot save data that was already dropped because the queue overflowed. And it cannot succeed if the network or the backend is unreachable for the whole of the time limit. Knowing these limits helps you design around them rather than hoping shutdown will fix everything.

What happens if shutdown is called twice

In real programs, more than one piece of code often believes it is responsible for shutting down the SDK. A framework hook may do it, an exit handler may do it, and the main function may do it as well. The specification says shutdown should be called only once, and that later calls should not do harm but may simply report failure or do nothing. That is helpful, because a second call is usually harmless.

It is still wise to give the responsibility to exactly one place. Two competing owners make it hard to know which call used the time budget and which one saw the result. A single, clearly named shutdown routine, called from the application’s single exit path, keeps the order predictable and makes the logged outcome trustworthy.

When the whole program runs for less time than one batch delay.

The most dramatic victims of missing shutdown logic are programs that run briefly. A command-line tool might finish in two seconds. A scheduled job might run for a minute and exit. A migration script might process a file and stop. With a five second batch delay and a sixty second metric interval, such a program may finish before the first batch is ever sent, and it can end with every span, metric, and log record still in memory.

The rule for short-lived programs

The rule is simple and strict. Before the program exits, whether it succeeds or fails, it must shut down the telemetry providers and wait for the result. This includes failure paths. A program that crashes with an unhandled error needs a handler that still performs shutdown, because the failure is exactly the case you most want to see.

A different kind of ending, where the process does not exit but simply stops running.

Serverless platforms such as function services add a twist. After a function returns its response, the platform may freeze the execution environment instead of destroying it. A frozen environment is paused: background threads, timers, and network activity all stop. If the batch processor’s timer was due to fire a second after the response, it does not fire, and the data waits in a frozen memory until the next invocation wakes the environment, which might be minutes or hours later, or never.

sequenceDiagram
  participant P as Platform
  participant F as Function code
  participant S as Telemetry SDK
  participant B as Backend
  P->>F: Invoke function
  F->>S: Record spans and metrics
  F->>S: Force flush before returning
  S->>B: Send pending data
  B-->>S: Acknowledge
  F-->>P: Return response
  Note over P,F: Environment may now be frozen, nothing is left waiting
        

Flush, do not shut down

In serverless, the same environment may be reused for many invocations, so the SDK must stay alive between them. Calling shutdown at the end of one invocation would stop the SDK, and every later invocation in the same environment would lose its telemetry. The correct tool is force flush, called at the end of each invocation before the response is returned. It empties the waiting room but leaves the SDK ready for the next call.

Time is billed

Flushing adds to the duration of every invocation, since the function must wait for the network call to complete before it can return. On platforms that charge by execution time, this has a direct cost, and it also affects the response time seen by callers. Some teams reduce the impact by sending telemetry to a nearby Collector or an extension running alongside the function, which accepts the data quickly and forwards it in the background, so the function only waits for a very short local handoff.

How a service is told to stop, and what it should do in the time it is given.

A web service might run for weeks, but it still ends eventually, and the way it ends is almost always through a signal. When an orchestrator such as Kubernetes wants to remove an instance, it sends a termination signal to the main process, waits for a grace period, and then forcibly kills the process if it is still running. The termination signal is your opportunity to shut down cleanly. If the process ignores it, the forced kill follows and any waiting telemetry is destroyed.

Budgeting the grace period

The grace period is a shared budget. Draining requests, flushing telemetry, closing database connections, and any other cleanup must all fit inside it. A common planning approach with a thirty second period is to give request draining about fifteen seconds, telemetry shutdown about five seconds, and leave the rest as a safety margin. If one stage overruns, the later stages are squeezed, and the telemetry stage is usually the last in line, which makes it the first casualty.

The race with the load balancer

There is a subtle timing problem in the first steps of termination. When an instance is marked as terminating, the systems that route traffic need a moment to notice and stop sending requests to it. During that short window, new requests can still arrive at an instance that has already received its termination signal. If the application stops its server the instant the signal arrives, those late requests fail, and the telemetry about them is either missing or full of connection errors.

Many teams handle this with a brief pause before the application begins to stop, often implemented as a pre-stop step that simply waits a few seconds. During the pause, the instance keeps serving normally while traffic drains away on its own. Only after the pause does the real drain begin. This pause also takes part of the grace period, so it must be included in the time budget. A thirty second grace period with a five second pause, a fifteen second drain, and a five second telemetry shutdown leaves only a five second margin, which is why budgets should be written down and checked, not assumed.

The sequence of stopping things decides whether the final spans exist at all.

It is tempting to shut down telemetry first, because it feels like a background concern, and then take care of the real application. This is backwards. If the providers are shut down while requests are still being served, every span, metric, and log record created after that moment is ignored. The in-flight requests, which are usually the most interesting ones during a shutdown, produce no telemetry at all.

flowchart TD
  A["Receive termination signal"] --> B["Stop accepting new requests"]
  B --> C["Wait for in-flight requests to finish"]
  C --> D["End any remaining open spans"]
  D --> E["Force flush all providers"]
  E --> F["Shut down all providers"]
  F --> G["Close other resources and exit"]
        

The sidecar ordering problem

Many deployments run a Collector or agent next to the application. When both are told to stop at the same time, the Collector may exit before the application has finished its final flush. The result is a failed export during shutdown, even though the application did everything right. The remedy is to keep the Collector alive for slightly longer than the application, using start-up and termination ordering features of the platform, or a short delay in the Collector’s own stop sequence.

A shutdown that never finishes is nearly as bad as one that never starts.

Exporters talk to the network, and networks fail. A Collector may be down, a connection may be slow, or a backend may be rejecting requests. During normal operation, exporters deal with this by retrying failed sends after a growing delay. This is sensible when time is plentiful, but during shutdown time is exactly what you lack. A retry loop that waits thirty seconds between attempts can consume the entire grace period and still end in a forced kill.

Choosing a shutdown budget

A good budget is long enough to send a normal final batch, which usually takes well under a second on a healthy network, and short enough that the process can never be blocked by an outage. For many services, a few seconds is plenty. For batch jobs that produce a lot of data at the end, a longer budget may be justified. The right value comes from measuring how long a normal final flush takes and adding a safety margin, not from guessing.

When the backend itself is the problem

Sometimes the reason shutdown is slow has nothing to do with the application. The Collector or backend may be overloaded or down. In that situation, exporters have probably been failing for a while, and their queues may already be full, with newer items being dropped to make room. A graceful shutdown at that point can only try to send data that the pipeline could not send during normal operation either, so it will usually fail within the time budget.

The lesson is that shutdown is not a magic recovery tool. It is the final step of a pipeline that must be healthy throughout its life. Teams that need stronger guarantees for outage periods use a local agent on each machine that accepts data quickly and holds it on disk until the remote side recovers. They also record how many items were abandoned at shutdown, so that a rise in abandoned data becomes a visible signal about the health of the whole pipeline rather than a private secret of each process.

The concept is universal, but the details differ from one ecosystem to the next.

Every OpenTelemetry SDK implements the same idea of flush and shutdown, but they differ in how much the SDK does for you automatically and how much you must wire up yourself. Because these details change with versions, the safest approach is to treat the following as a map of what to look for rather than a guarantee, and to confirm the exact behaviour in the documentation of your SDK.

A checklist for any language

Whatever language you use, ask the same questions. Does the SDK register an exit hook, and does it run in my deployment? Is there an explicit shutdown call, and who calls it? Does the call return something I must wait for? Can I give it a timeout? What happens when my process receives a termination signal? What happens when my process crashes? The answers to these questions, written down once per service template, prevent the majority of shutdown bugs.

Each signal has its own quirks when the end arrives.

Although flush and shutdown apply to all three signals, each one behaves a little differently, and knowing the differences helps you decide what to expect after a clean shutdown. A common mistake is to flush the tracer provider but forget the meter provider and the logger provider, leaving two of the three signals exposed.

Traces

For traces, only finished spans are exported. A span that has started but not ended is still being built, and it is not in the queue. This means that a long-running operation interrupted by shutdown will leave no trace at all unless it ends its span. It is good practice for code that is interrupted to end its span with an error status describing the interruption, so that the trace tells the story of what was cut short.

Metrics

For metrics, the periodic reader normally performs one final collection when it is shut down, gathering the current aggregated values and sending them. This is why a clean shutdown recovers the partial interval at the end, which would otherwise be lost. With cumulative reporting, the final data point carries the latest totals. With delta reporting, it carries the activity since the last export, which is precisely the part that would have been lost.

Logs

For logs, the batch processor holds records in its queue until the next batch. The last records before an exit are usually the most important ones, such as a fatal error or a message announcing the shutdown itself. A clean shutdown sends them, while a kill leaves them behind. Teams that also write logs to standard output often keep that path as a second copy, because it is collected by the platform independently of the SDK.

Seeing the loss with self-observability

You cannot fix what you cannot see, and lost telemetry is invisible by nature. Fortunately, the telemetry pipeline can report on itself. SDKs and Collectors expose their own metrics about how many items they have received, how many they have sent, how many are waiting in queues, and how many were dropped or failed to send. The exact names and the level of detail differ between languages and versions, and the conventions for them are still maturing, so check what your own components offer.

Treat these self-metrics as a first-class part of your dashboards. A steady, small queue and a flat line of zero drops are signs of a healthy pipeline. A queue that climbs, a rising count of failed exports, or a burst of dropped items at deployment times are signs that something in the ending is going wrong. Because these numbers come from the pipeline itself, they reveal losses that no ordinary application metric could ever show.

The same problem exists one hop later, inside the Collector itself.

The application is not the only place where data waits. The OpenTelemetry Collector has its own batching, its own queues in front of exporters, and its own retry logic. When a Collector is stopped, any data inside it that has not yet been sent shares the same fate as data inside an application. A perfect shutdown in the application is wasted if the Collector then loses the data a moment later.

flowchart LR
  A["Applications flush on shutdown"] --> B["Agent Collector batches and queues"]
  B --> C["Gateway Collector batches and queues"]
  C --> D["Backend"]
  E["Stop order: applications, then agents, then gateways"] -.-> A
        

Stop from the edge inward

In a layered design with agents near the applications and gateways further away, the order of stopping matters just as it does inside an application. Applications must finish first so that they can flush into the agents. Agents must stop next so that they can pass their data to gateways. Gateways stop last. If a gateway is replaced before the agents that feed it, those agents will fail their exports, retry, and may lose data when their own queues overflow.

Rolling updates of the Collector tier

Collectors are usually deployed with several replicas, and updates replace them one at a time. This works well for stateless forwarding, but stateful stages, such as tail sampling that buffers whole traces in memory, lose their buffered data when an instance is replaced. Plan these updates carefully, replace one instance at a time, and accept that a small number of traces may be incomplete during the change.

Some endings give no warning, so the design must limit the damage in advance.

Graceful shutdown depends on the process having a chance to run code at the end. Some endings give no such chance. A process killed by a forced signal after the grace period, one terminated by the operating system for using too much memory, a machine that loses power, or a crash in native code all skip any cleanup. In those cases no flush is possible, and whatever was waiting in memory is gone.

Designing for the ending you cannot control

Since you cannot flush in these cases, the goal becomes making the amount of data at risk small, and making it more likely that important data left the process earlier. Several techniques help, and teams usually combine them.

A worked estimate for a hard kill

Return to the instance that records about two hundred spans per second. With a five second batch delay, a hard kill can destroy up to about a thousand spans. If the team shortens the delay to one second, the exposure falls to about two hundred spans. That is a five-fold reduction, but the price is paid constantly, not only at the end. A time-triggered batch processor that sent twelve batches per minute now sends sixty, which is five times as many network calls, five times as many serialisations, and five times as many small requests for the Collector to handle.

The comparison shows why a local agent is often the better answer. It lets the application keep a relaxed batch schedule while the data still leaves the process quickly, and the agent, which is much less likely to be killed at a random moment, takes over the job of holding and retrying it.

Doing shutdown well is cheap, but it is not entirely free.

The cost of the alternatives

Teams that skip graceful shutdown sometimes try to compensate by shortening batch delays to a fraction of a second. This reduces the loss window but increases the number of network calls many times over, raises CPU use for serialising small batches, and loads Collectors with a constant stream of tiny requests. Graceful shutdown solves the same problem at the exact moment it occurs, at a tiny fraction of the cost.

Deciding how much effort to invest

Not every service needs the full set of protections. A simple way to decide is to ask two questions. First, how costly is it if the final seconds of this service’s telemetry are missing? A payment service during an incident answers differently from an internal reporting tool. Second, how often does this service end? A service that is replaced a dozen times a day loses far more than one that runs for months.

For almost every service, the basics are worth doing: a shared shutdown routine, signal handling, and a time budget. The heavier measures, such as local agents with persistent queues and shorter batch delays, are best reserved for the services where both answers are high. Starting with the basics everywhere and adding more only where evidence demands it keeps the effort proportionate.

The end of a process still needs the same care as the middle.

Shutdown looks like a purely operational topic, but it has security aspects worth remembering. During shutdown the process makes a final burst of network calls, sending whatever remains in its queues. Those calls must follow the same rules as any other export: they should use encryption, they should authenticate to the receiving Collector, and they should send only data that is allowed to leave the process.

Data left on disk

Persistent queues write unsent telemetry to disk so that it survives restarts. That data may include everything the application exports, so the directory that holds it needs the same protection as any other store of telemetry: restricted permissions, encryption at rest where required, and a clear retention rule so that old unsent data does not accumulate forever.

Where teams most often discover the problem, usually by accident.

The following scenarios describe patterns that appear again and again across the industry. Each one starts with a puzzling symptom and ends with a missing flush as the cause.

Habits that keep endings clean, and traps that cause silent loss.

flowchart TD
  A["What kind of process is this?"] --> B{"Does it run for a long time?"}
  B -->|Yes| C["Handle termination signal, drain, flush, then shut down"]
  B -->|No| D{"Is it a serverless function?"}
  D -->|Yes| E["Force flush before every response, never shut down per call"]
  D -->|No| F["Wrap work in a span, then shut down providers before exit"]
        

Patterns that work

Anti-patterns to avoid

Because the failure is silent, you must test for it on purpose.

Shutdown bugs never announce themselves. The system looks healthy during normal operation, and the only symptom is missing data at the end. The only reliable way to find these bugs is to test the ending directly, in environments that behave like production, and to keep watching for signs of loss afterwards.

Rehearse a real rollout

Unit tests prove that your shutdown helper works. Only a rehearsal proves that your deployment works. Pick a staging environment that matches production, generate a steady stream of traffic that carries a countable marker, and trigger a rolling update. Afterwards, compare the number of requests your load generator sent with the number your telemetry recorded. The two should agree closely. If the telemetry is short by roughly one batch per instance, you have found a missing flush. If it is short by much more, look for signals that never arrive, grace periods that are too small, or a Collector that stops too early.

Repeat the rehearsal whenever something in the chain changes: a new SDK version, a new base image, a new startup script, or a new Collector release. Each of these can quietly break the path of the termination signal or change a default timeout. A rehearsal takes only a few minutes, and it turns shutdown from a hope into a measured property of your system.

Short answers to the questions people ask most often.

Because SDKs batch data in memory and send it later on a timer or when a size limit is reached. If the process ends while data is still waiting, nothing ever sends it.

Force flush sends pending data now and leaves the SDK running. Shutdown sends pending data and then stops the SDK permanently, releasing its resources. Shutdown is meant to be called once.

No. Use force flush before returning the response. Shutdown would stop the SDK, and later invocations in the same reused environment would lose their telemetry.

It depends on the language and on whether you use an agent. Some SDKs register an exit hook for normal exits, while others require an explicit call. Even where a hook exists, it does not cover forced kills or crashes.

No. Only spans that have ended are exported. Code that is interrupted should end its span, ideally with an error status that explains the interruption, before shutdown runs.

Roughly one batch delay of spans and logs, often about five seconds, and up to one export interval of metrics, often about a minute, plus any spans not yet ended. The exact amounts depend on your configuration.

Measure a normal final flush, allow several times that duration, and make sure it fits inside the platform’s grace period alongside request draining. A few seconds is enough for many services.

Often because the application is started through a shell wrapper that does not forward signals, so only the forced kill reaches it. Make the application the main process or ensure the wrapper passes signals along.

It can. A clean stop tries to drain its pipeline, but in-memory queues are lost on a forced kill. Persistent queues and careful stopping order, from applications to agents to gateways, reduce the loss.

Typically yes. Periodic readers usually perform one last collection and export when they are shut down, which recovers the partial interval at the end. Confirm this for your SDK version.

Not fully. Those endings skip cleanup code. You reduce the damage by shortening batch delays where needed, exporting to a local agent, using persistent queues, and installing a last-chance error handler where possible.

No. Shortening the delay shrinks the loss window but raises network and CPU cost all the time, and still loses data. Graceful shutdown handles the ending itself at almost no ongoing cost, and the two can be combined where needed.

OpenTelemetry keeps recording cheap by batching telemetry in memory and sending it in the background. That design is excellent for performance, but it creates a waiting room where data sits until the next batch goes out. When a process ends before the waiting room is emptied, the data is lost silently. Because the newest data is the most likely to be waiting, the loss falls on exactly the moments you care about most: the final requests, the last errors, and the final partial interval of metrics.

Graceful shutdown and flushing are the discipline that closes this gap. Force flush empties the waiting room at natural boundaries, such as the end of a serverless call. Shutdown empties it one last time and then stops the SDK for good. Done in the right order, with intake stopped first, in-flight work drained, spans ended, and telemetry shut down last with a firm time budget, they preserve the story of every process’s final moments. Extend the same care to Collectors, plan for the endings that cannot be graceful, and test the ending on purpose. Like locking the door when you leave, it takes a moment and protects a great deal.