Work out the manual route before the deadline, not during it

The dependency is invisible until it fails

A step that has worked every day for three months stops being thought of as a dependency and starts being thought of as part of the desk. Then it is slow, or unreachable, or returning something subtly different from yesterday, and you discover how much of the schedule was resting on it.

The failure modes are not only outright unavailability, which is at least obvious. Degradation is more common and more awkward: responses that take four times as long, capacity limits reached earlier than expected, or output that is noticeably different in character from what the process was built around.

Nothing about any of this is unusual for an external service. What is unusual is how rarely a plan exists, because the step arrived informally and never went through the questions a formal dependency would have faced.

Ask what happens if it is gone on the worst day

The exercise takes fifteen minutes and it is worth doing when the process is built rather than when it breaks. Pick the least convenient moment in your cycle — the afternoon before a publication, the last day of a reporting period — and ask what you would actually do.

The answers fall into three groups. Some work can be done by hand more slowly, which is fine if the schedule has room. Some can be deferred, which is fine if somebody has agreed that it can. And some cannot be done at all without the step, which is the finding that matters, because it means a dependency has become a single point of failure without anyone deciding that it should.

Write the answer down next to the process. A contingency that exists only in the head of the person who built it is not available on the day they are away, which is when it will be needed.

Buy back time in the schedule rather than in the process

The most effective protection is usually not technical. Finishing a day early, generating the material the week before rather than the morning of, and keeping a small stock of completed work all convert an outage into an inconvenience.

That is the same defence anybody would apply to a supplier they cannot control, and it applies here for the same reason. The step is fast, which tempts people to schedule it late, and scheduling it late is what turns a small disruption into a missed deadline.

Where the work is genuinely last-minute by nature, reduce the amount that depends on the step. Prepare everything that can be prepared in advance, so that what remains on the day is small enough to do by hand if it has to be.

Under time pressure, checking is the first thing to go

The specific danger of a deadline is not that the tool fails. It is that it half-works, and the checking step is quietly skipped because there is no time, which is precisely the day on which something plausible and wrong goes out.

The countermeasure is to decide in advance which checks are non-negotiable and which may be dropped, and to write that down while nobody is under pressure. A short list saying that the figures are always verified and the sampling pass may be reduced is a decision made calmly, applied hastily.

It is also worth having a smaller acceptable output defined in advance. A shorter piece, fewer items, a simpler format: shipping a reduced version fully checked is nearly always better than shipping the full version unchecked, and having named the reduced version beforehand makes it a choice rather than a scramble.

Some deadlines should not have this step in them

For work where the deadline is hard and the consequences of missing it are severe, the honest question is whether an uncontrolled dependency belongs in the critical path at all. If the answer to the outage scenario is that the deadline is missed, then the process has taken on a risk in exchange for speed, and somebody should have agreed to that trade explicitly.

Occasionally the right conclusion is to keep the manual method as the primary route and use the faster one only when it is available and there is time to check it. That sounds like giving up an advantage and it is really just refusing to depend on something you cannot repair.

And do not let the fallback rot. A manual route nobody has used in a year is a document rather than a capability, so run it deliberately once in a while, on a quiet day, with the person who would have to do it in an emergency.