Time-to-Recover (TTR) / Time-to-Survive (TTS)

1. What Is Time-to-Recover (TTR) / Time-to-Survive (TTS)?

Time-to-Recover (TTR) and Time-to-Survive (TTS) are companion metrics that quantify supply chain resilience in practical, decision-ready terms.

• Time-to-Recover (TTR): The time it takes for a disrupted node in your supply chain (e.g., plant, supplier site, warehouse, port, logistics lane) to restore output to its pre-disruption level. TTR reflects the full path to recovery—repairs, requalification, labor ramp, tooling transfers, permits, and logistics normalization.
• Time-to-Survive (TTS): The maximum duration your network can continue meeting demand if a specific node goes offline, given current inventory, in-transit stock, alternate capacity, and feasible reroutes/substitutions.

The core idea is simple: if TTS is greater than or equal to TTR, you can “survive” the disruption without failing customers. If TTR exceeds TTS, you have a shortfall window in which service will break unless you implement mitigations (e.g., buffers, alternate sources, flexible routing). In plain language: TTR tells you how long you’re down; TTS tells you how long you can cope.

This is an operational resilience framework within Risk, Resilience & Continuity. It is widely used by consultants, supply chain leaders, and enterprise risk teams to set inventory and capacity buffers, support sourcing and footprint decisions, and build credible business continuity plans anchored in numbers rather than abstractions.

2. Origin and Background

Popularization: Mid-2000s, associated with the MIT Center for Transportation & Logistics. The concepts were widely disseminated through management articles and books on supply chain resilience and have since been adopted by industry bodies and consulting practices. The precise origin is difficult to assign to a single source, but the approach gained prominence through academic-practitioner collaboration and case-based evidence.

The framework emerged to address a practical gap: leaders needed a way to translate “resilience” into measurable exposure and concrete trade-offs (e.g., how much safety stock to carry, when to dual-source, whether to add a second site). TTR/TTS became popular because they connect directly to service outcomes and can be calculated at the product, site, or network level with existing operational data.

3. How Time-to-Recover (TTR) / Time-to-Survive (TTS) Works

The logic rests on comparing two time-based measures for a given disruption scenario:

• TTR (Time-to-Recover): For each critical node, estimate the calendar time to restore capacity to baseline after a defined disruption (e.g., fire, flood, cyber outage, labor strike). TTR is scenario-specific and includes all real-world lags: repair or relocation time, supplier and regulator requalification, tooling transfer, workforce availability, and logistics constraints.
• TTS (Time-to-Survive): For the same disruption, compute how long the rest of the network can meet demand without that node. TTS accounts for on-hand and in-transit inventory, alternative sources and sites, pre-qualified substitutes, expediting options, and realistic rerouting limits.

Interpretation is intuitive: if TTS ≥ TTR, the business can continue to serve customers (possibly at higher cost) while recovery completes. If TTR > TTS, the difference is the exposure window where demand cannot be fully met.

For communication, many teams use the simple relationship: “Service shortfall window = max(0, TTR − TTS).” In plain terms, it’s the time during which you will not be able to supply, unless mitigations are in place.

Key components and choices

• Unit of analysis: Product family/SKU, node (plant, supplier site, DC), lane/port, or a specific bill-of-material (BOM) component.
• Time horizon and granularity: Typically weeks; sometimes days for fast clockspeed sectors (e.g., electronics, consumer). Use consistent buckets across the analysis.
• Demand basis: Normal, peak, or scenario-specific demand. Many teams compute TTS under multiple demand profiles (baseline, promotion, launch, peak season).
• Feasibility constraints: Regulatory approvals, tooling compatibility, minimum batch sizes, campaign schedules, labor shifts, transportation lead times, and allocation constraints with suppliers.
• Alternatives and substitutions: Pre-qualified second sources, alternate specs or SKUs customers will accept, and cross-plant production flexibility.

Data requirements

• BOMs and critical component mappings (including multi-tier where possible).
• Inventory levels (finished goods, WIP, raw), by location; in-transit stock; planned arrivals.
• Capacity by line/site (rated vs. practical), changeover times, and utilization.
• Supplier lead times, minimum order quantities, and qualification/requalification times.
• Logistics lead times and alternate lane capacities.
• Customer service requirements (fill rates, allowable backorders, contractual penalties).

Analytical approaches

• Heuristics: Time-phased material balance in weekly buckets; conservative but fast for initial screening.
• Linear programming / max-flow: Optimize product allocation across remaining capacity and inventory to maximize service time.
• Digital twin or simulation: Model dynamic behavior (batching, changeovers, transport variability) for greater fidelity on TTS and realistic recovery ramps for TTR.

4. When to Use TTR/TTS

TTR/TTS is most helpful when you need to quantify exposure and size mitigations with confidence, rather than rely on abstract risk ratings. Common use cases include:

• Inventory policy and strategic buffers: Setting safety stocks and positioning inventory to meet resilience targets (e.g., “TTS ≥ 8 weeks for top 50 SKUs”).
• Diversification and dual-sourcing: Evaluating the value of second sources, alternate sites, or tooling redundancy by comparing the TTR–TTS gap before and after.
• Network design and footprint strategy: Informing nearshoring/regionalization and site selection by stress-testing critical nodes.
• Supplier risk management: Prioritizing supplier development or financial support where long TTR meets short TTS.
• Business continuity planning: Creating product- and site-specific playbooks with quantified triggers and coverage times.
• Customer commitments and SLAs: Ensuring launch and service promises are backed by adequate TTS.

Especially powerful when

• You need to translate resilience into concrete, testable targets for S&OP and capital/inventory investments.
• Executive decisions hinge on “how much buffer is enough?” rather than “what could go wrong?”
• Products have long lead times or complex qualifications, making TTR inherently long and variable.

Less suitable or potentially misleading when

• Demand is highly volatile and unmodeled; TTS computed on outdated demand will mislead.
• Disruptions are systemic (e.g., multi-country conflict) and invalidate assumed alternatives; the analysis must expand to multi-node scenarios.
• Alternative capacity is theoretical (e.g., unqualified supplier, incompatible tooling); counting it inflates TTS unrealistically.

In practice, teams often use TTR/TTS as a backbone metric, then layer scenario planning to capture correlation and tail risks.

5. How to Apply TTR/TTS: Step-by-Step

1. Clarify scope and resilience targets

   Define the products/SKUs, customers, and geographies in scope and the disruption scenarios to analyze (e.g., loss of supplier site A, shutdown of plant B, closure of port C). Align on targets (e.g., “For top-100 SKUs, ensure TTS ≥ TTR for single-node outages up to 8 weeks”). Decide time buckets (weeks vs. days) and demand basis (baseline, peak, launch).

2. Map nodes and critical dependencies

   Identify critical nodes: plants, contract manufacturers, tier-1 and key sub-tier suppliers, distribution centers, and logistics lanes. Trace BOM dependencies for revenue-critical SKUs and map where each component is produced and finished goods are made and stored.

3. Assemble data

   Gather inventory (by location and status), in-transit stock, capacity and utilization by line/site, supplier lead times, qualification requirements, logistics lead times, and service expectations. Document data quality issues explicitly and set assumptions with owners.

4. Estimate TTR for each node and scenario

   Build TTR bottoms-up with realistic ramps: repairs/replacement, tooling transfer times, regulatory or customer requalification, workforce availability, and logistics restart lags. Distinguish optimistic, base, and conservative TTR where uncertainty is high; use historical incident data where possible.

5. Compute TTS for each product-node pair

   For each disruption, remove the node’s contribution and time-phase supply vs. demand using remaining inventory, in-transit stock, and feasible alternative capacity/routes. Consider changeovers, minimum batches, shared capacity with other products, and substitution rules. TTS is the number of time buckets you can meet demand until the first shortfall occurs.

6. Compare TTR vs. TTS and quantify exposure

   Create a simple scorecard: for each SKU-node pair, show TTR, TTS, and the shortfall window (max(0, TTR − TTS)). Aggregate exposure across products by revenue, margin, or strategic criticality to focus attention on the “critical few.”

7. Design mitigations and test options

   For gaps, evaluate levers and re-run TTS to measure impact:

   • Increase buffers (FG, WIP, raw) in specific nodes; pre-position inventory regionally.
   • Qualify second sources or second sites; add tooling redundancy; negotiate allocation clauses.
   • Enhance cross-plant flexibility and alternate routings; pre-book surge logistics options.
   • Approve temporary product substitutions or spec flex with customers.
   • Accelerate recovery (reduce TTR) via contingency contracts, rapid repair kits, and pre-approved requalification protocols.

   Quantify cost-to-serve impact vs. avoided revenue loss to build the business case.

8. Embed into S&OP and governance

   Translate decisions into inventory targets, sourcing agreements, capacity plans, and supplier requirements. Integrate TTR/TTS metrics into monthly S&OP and risk reviews; set triggers (e.g., when port dwell time exceeds X days, release alternate routing plan).

9. Refresh and extend

   Update quarterly for critical portfolios, or after material changes (new products, suppliers, regulations). Progressively extend coverage to more SKUs and multi-node scenarios (e.g., simultaneous disruption of a site and a port).

6. Example: TTR/TTS in Action

Context: A $3.5B global medical devices company relies on a single Asian supplier for a sterilized tubing component used in its top-selling catheter line. Regulatory requalification is lengthy, and the company faces seasonal demand peaks.

Problem: Leadership suspected a single point of failure but lacked quantified exposure to justify dual-sourcing, added tooling, or higher buffers. Finance was wary of carrying more inventory without clear returns.

Application: The team computed TTR and TTS for the tubing component and the finished catheter. TTR for the supplier site was estimated at 14 weeks (facility repair, regulator re-approval, and revalidation lots). TTS, under peak-season demand, was 6 weeks given on-hand and in-transit inventory and limited cross-plant flexibility. The resulting 8-week shortfall window translated to $140M revenue-at-risk and potential SLA penalties with hospital networks.

Mitigations tested:

• Increase FG safety stock by 3 weeks for top SKUs; pre-position inventory in two regions.
• Qualify a second supplier for tubing with pre-approved design equivalence; add a backup sterilization route.
• Invest in duplicate tooling at a second contract manufacturer to enable 60% ramp within 6 weeks.
• Negotiate substitution tolerance with key customers (alternate catheter variant acceptable for specific procedures).

Results: After implementing the plan, TTS improved to 12 weeks and TTR was reduced to 10 weeks via pre-arranged requalification protocols—closing the gap. The company cut peak-season service-at-risk by 80% and reduced emergency expediting costs by 35% year over year. Finance approved the inventory uplift based on modeled avoidance of lost revenue and penalties.

7. Strengths and Limitations

Strengths

• Actionable and intuitive: Time-based metrics are easy for executives and operators to grasp and link to real decisions.
• Quantifies trade-offs: Directly informs how much inventory, capacity flexibility, or dual-sourcing is warranted.
• Granular and comparable: Works at SKU, product family, site, or network level; enables apples-to-apples comparisons.
• Integrates with planning: Fits naturally into S&OP, supplier management, and business continuity playbooks.
• Scenario-ready: Supports what-if analysis across disruptions and demand seasons.

Limitations

• Data dependency: Requires accurate, time-phased inventory, capacity, and qualification data; gaps can distort TTS.
• Static assumptions: Often ignores dynamic behaviors (bullwhip effects, behavioral responses) unless simulated.
• Single-node bias: Standard TTR/TTS focuses on one node at a time; systemic or correlated shocks need multi-node scenarios.
• Uncertain TTR: Recovery times are estimates and can be optimistic without pre-negotiated plans and evidence.
• “Theoretical capacity” trap: Counting unqualified or practically constrained alternatives can overstate TTS.

8. Common Pitfalls (and How to Avoid Them)

• Using average demand instead of peak or realistic profiles
  • What goes wrong: TTS looks adequate until peak season exposes a gap.
  • How to avoid: Calculate TTS under baseline, peak, and launch scenarios; set targets to the most demanding relevant profile.
• Counting unqualified alternatives
  • What goes wrong: TTS is inflated by suppliers/sites that are not certified, tooled, or contractually obligated.
  • How to avoid: Only include pre-qualified alternatives with tested ramps and contracts; treat others as future options, not current TTS.
• Ignoring sub-tier dependencies
  • What goes wrong: Multiple tier-1 suppliers appear diversified but share the same sub-tier, creating a hidden single point of failure.
  • How to avoid: Map critical sub-tier components for top SKUs; include shared sub-tier risks in scenarios and TTR/TTS calculations.
• Assuming instantaneous recovery
  • What goes wrong: TTR assumes a step-change back to full capacity, ignoring ramp and learning curves.
  • How to avoid: Model recovery ramps; use staged TTR (e.g., 50% capacity by week 6, full by week 10).
• Not reflecting logistics realities
  • What goes wrong: TTS assumes alternate routes without considering carrier capacity, port congestion, or customs lead times.
  • How to avoid: Include lead times and lane capacities; pre-arrange surge capacity and test routings.
• One-size-fits-all targets
  • What goes wrong: Overinvesting in low-criticality items while leaving crown jewels exposed.
  • How to avoid: Set differentiated TTS targets by product criticality, margin, and customer SLA sensitivity.
• Failing to update
  • What goes wrong: New products, suppliers, or contracts change TTR/TTS, but decisions use stale metrics.
  • How to avoid: Refresh quarterly for critical portfolios; trigger updates after significant network changes.

9. How TTR/TTS Relates to Other Frameworks

• Supply Chain Risk Heat Map: Use heat maps to prioritize which nodes and risks to analyze; apply TTR/TTS to quantify exposure and size mitigations.
• Resilience Maturity Model: Maturity assessments set capability targets (e.g., multi-tier visibility, playbooks). TTR/TTS provides the quantitative yardstick and outcomes those capabilities should achieve.
• Kraljic Portfolio Matrix: Segment categories by supply risk and profit impact; set differentiated TTR/TTS targets and mitigation strategies by segment.
• FMEA and Bow-Tie Analysis: Deep dive into failure modes and barriers for high-risk nodes; use TTR/TTS to gauge the net effect on service and justify controls.
• SCOR (Supply Chain Operations Reference): TTR/TTS complement SCOR metrics by linking reliability and responsiveness to disruption survivability.
• Scenario Planning and Stress Testing: Extend beyond single-node events to correlated or systemic shocks; use TTR/TTS as inputs and validation metrics.
• Digital Twins: High-fidelity models that compute TTS under realistic dynamics and test TTR improvement levers (e.g., accelerated requalification, flexible labor).

Together, these tools form a coherent toolkit: heat maps for prioritization, TTR/TTS for quantification, deep-dive analyses for root causes and mitigations, and maturity models to institutionalize capabilities.

10. Key Takeaways

• Time-to-Recover (TTR) measures how long a disrupted node takes to restore capacity; Time-to-Survive (TTS) measures how long you can meet demand without it.
• The critical decision metric is the gap: if TTR > TTS, you face a service shortfall unless you add buffers, alternatives, or faster recovery.
• TTR/TTS translate resilience into actionable targets for inventory, sourcing, capacity, and routing—and fit naturally into S&OP and BCPs.
• Quality of assumptions matters: use realistic ramps, qualified alternatives, and multiple demand profiles; refresh regularly.
• Combine TTR/TTS with scenario planning to capture correlations and tail risks, and with maturity models to sustain capability improvements.

11. FAQs About Time-to-Recover (TTR) / Time-to-Survive (TTS)

Is TTR the same as MTTR (Mean Time to Repair)?
No. MTTR is a maintenance metric for equipment repair duration. TTR is broader: it covers end-to-end recovery of supply capacity, including requalification, tooling transfers, labor, and logistics. A site’s MTTR might be short while overall TTR remains long due to regulatory or supply constraints.

How do we calculate TTS in practice?
Time-phase demand against available buffers and alternative capacity after removing the disrupted node. Start with on-hand and in-transit inventory, then allocate remaining production across feasible sites and routes, honoring lead times, changeovers, and substitutions. TTS is the number of time buckets you can fully meet demand before the first stockout.

Should TTR/TTS be computed at SKU level or product family?
Both. Use SKU-level analysis for revenue-critical or constraint-bound items. Roll up to product families for executive decisions. Many organizations tier the depth: detailed for the top 50–200 SKUs, heuristic for the long tail.

How long does it take to implement TTR/TTS?
A focused pilot for a critical product family typically takes 4–8 weeks using available data and heuristics. Expanding to an enterprise view with multi-tier mapping, simulation, and governance embedding often takes 10–16 weeks, followed by quarterly refreshes.

Can smaller companies use TTR/TTS without advanced tools?
Yes. Start with spreadsheets and weekly buckets for your top products and most critical nodes. Use simple rules for allocations and conservative assumptions. As you mature, move to optimization or simulation and integrate with your planning systems.

What if multiple nodes fail at once?
Run multi-node scenarios via scenario planning or a digital twin. Standard TTR/TTS is single-node by design; to capture correlated risks (e.g., regional disasters), extend the analysis to simultaneous outages and validate that alternatives remain viable.