Two hours into a major outage an executive asks for a restoration time. The team's honest position is "probably three hours, unless the data is inconsistent, in which case a day." What happens if you give the three-hour number, and what should you say instead?

What happens if you give the number

The three-hour figure leaves the room and stops being an estimate. Support commits to it with customers, the sales team repeats it to an account, a public status page repeats it, and the executive plans a board update around it. None of those people carry the conditional you attached, because a number travels and a caveat does not.

At hour three the system is not restored. The conversation is now about your credibility rather than about the outage, the executive starts asking for updates every twenty minutes, and the team loses the engineer who was actually fixing it to the update cycle. The second failure is organisational and it is usually more expensive than the first thirty minutes of the incident.

What to say instead

Commit to what you control. You cannot promise a restoration time; you can promise an update time.

• The shape of the answer: "Two scenarios. If the data is consistent, which we will know by 15:00, restoration takes about three hours from that point. If it is not, it is a day. I will tell you which at 15:00."
• Name the decision the executive actually has to make, because they are rarely asking out of curiosity. Usually it is whether to notify customers, invoke a contractual clause, or move staff onto manual processing. Give them the trigger, not the timeline: "if you need to decide about customer notification, decide on the assumption of a day, because that is reversible and the other direction is not."
• Separate restore from recover. Service back is not data reconciled, and not backlog cleared. Executives generally hear "fixed" as all three, and the gap between them is where the next disappointment lives.

Why the instinct to give a number is so strong

Because refusing feels like evasion, and because the engineer genuinely believes the optimistic branch. Optimism under pressure is not a character flaw, it is a well-documented estimation bias, and the standard correction is to quote the pessimistic branch when the difference between branches is large and the cost of being wrong is asymmetric.

What a strong answer adds

The update cadence is a product of the incident and should be designed before one happens. A fixed rhythm — every 30 minutes, same format, same channel, even when the update is "no change, next update at 15:30" — removes the pull on the responders, and it is what stops the executive from asking. Publishing "no change" on schedule is the thing that buys trust, because it proves the silence is not concealment.

Common weak answers

• "We don't have an ETA yet." True and useless: it gives the executive nothing to act on and guarantees they ask again in ten minutes.
• "Three hours", stated with private mental reservations. The reservation does not travel and you have made a commitment you did not intend to make.