The network has no uptime

Yesterday, for the whole later part of the day, everything I run the company on went down. The AI services underneath the work - the ones I now lean on to draft, to research, to keep a long job moving while I do something else - just stopped. And the honest part is how much stopped with them. The dependency is quite high now. I had two long jobs running and both of them stalled, and I sat there realising I could not really finish anything until the services came back up.

So this is not a story about a clever opener or a reply rate. This is about the morning after, when the services came back and I looked at what had actually survived the outage. Because two things did not go down, and they turned out to be the only two things that matter.

What went down

Nearly all of the leverage. That is the honest word for it. I have built a way of working where a lot of the busy part - finding the person, reading their world, drafting the first version, keeping a job running for twelve hours - is handed to a machine. When the machine went dark, that whole layer went dark with it. No drafts got written. No research got done. The loop that had been running for half a day just stopped and needed me to come back and restart it by hand, and it could not even do that part on its own.

I am not going to pretend that felt fine. It did not. You build all this so the day runs without you standing over it, and then for an afternoon it does not run at all, and you notice exactly how much you had quietly handed over.

What did not go down

Two meetings on the calendar. Ten real conversations with people who had replied and wanted to keep talking. None of that moved an inch during the outage, because none of it lived inside the layer that broke. The meetings were booked with people who already knew us. The conversations were with a network built over years, one message at a time, most of them sent by hand long before any of this automation existed.

That is the whole point, and I nearly missed it. The relationships have no uptime. There is no status page for whether someone trusts you. A person who knows you does not go offline because a data centre did. The two meetings did not cancel themselves. The ten conversations did not return an error. They sat exactly where they were, waiting for me to come back, and they would have sat there whether the outage lasted a day or a week.

The numbers are small, and that is the argument

Two meetings. Ten qualified conversations. Three email addresses I actually have permission to use. If you came here for a big number, that is it, and I am not going to inflate it. On an account with more than eighteen thousand messages of history, the pipeline that is actually real - people who replied and meant it - is small. Almost all of those eighteen thousand messages were sent by hand, over years, not blasted by a tool last week.

I used to think the goal was to make that top number bigger. Send more, faster, with less of me in it. The outage argued the other way. The eighteen thousand is not the asset. The two and the ten are the asset, because they are the part that was still there the next morning. Everything I had automated was gone for an afternoon. Everything I had actually built by hand was untouched.

Where the leverage belongs

So I am not against the automation. I depend on it, clearly - that is the whole reason the outage stung. The machine that drafts and researches and keeps a job moving for twelve hours is real leverage, and I would not give it up. But leverage is the right word, and it is worth being precise about it. Leverage is a longer arm on the thing you already have. It is not the thing itself. When the arm breaks, you still have the thing. When you mistake the arm for the thing, a bad afternoon becomes an empty pipeline.

The mistake I see people about to make - the one I was halfway into myself - is building the whole business on the layer that has an uptime. Pointing a tool at ten thousand strangers, letting it run unattended, treating the send volume as the pipeline. That works right up until the day it does not, and on that day you find out there was never anything underneath it. No relationship. No reason for anyone to reply once the volume stops. Just a machine that was doing all the talking, now quiet.

The other way round is slower and it is boring and it is what actually held. Work the network you already have. Send fewer, by hand, to people who have a reason to know your name. Let the machine take the busywork - the finding, the reading, the first draft - but keep your own hand on the part that is a relationship, because that is the part with no status page. A tool that runs in your browser, drafts and finds and remembers, then stops and waits for you to send it yourself - that tool going down for an afternoon costs you an afternoon. It does not cost you your network, because your network was never inside it.

The morning test

Here is the test I am keeping from this. Picture your pipeline the morning after every tool you use goes down for a day. What is still standing? If the answer is "nothing, I have to wait for the services to come back," then the tools were not helping you build something - they were the thing, and you were renting it. If the answer is "the people who know me are still there, the meetings are still on the calendar," then you built the durable part and the tools were doing what tools are for.

My answer yesterday was better than I expected and worse than I would like. Two meetings and ten conversations survived, which is the real business. A whole afternoon of leverage did not, which is more of my day than I had realised I was leaning on a thing with an uptime.

I am keeping the leverage. But I am going to spend the next while making the two and the ten bigger the slow way, by hand, one person at a time - because those are the numbers that were still on the screen the next morning.

---

Sources

Every figure in this story traces to a source that was opened. This story rests entirely on first-party data, per the 2026-08-20 / 2026-08-21 precedent: the web returned no citable primary, only vendor SEO blogs.

First-party - Reach team meeting transcript, 2026-09-04

Drive doc 1mU5VM2KcV8E0_X4ll2a40JfdmwYdoK9DWGYGIIsyGEA, Transcript section (opened and read in full, not the Gemini summary).

• The outage, Pravin Luthada's own words (00:00:49): "yesterday the whole later part of the day at least for me the everything was down. uh so like [Claude] and codex and such so the work was not um completed and uh yeah so nowadays um the dependency is quite high unfortunately." (Transcript garbles "Claude" as "lord"; corrected.)
• The long-running jobs (00:02:27): "this is the loop that I've now been running now for since 12 12 hours or so, but it got like stopped yesterday and now it was able to resume it. it always needs um some sort of persistence that it is not able to do especially with the extension and all. So yeah, I think I have two loops running and both of them are just um yeah I should stop one of the loops I feel otherwise I will not be able to complete anything."
• The reach platform itself was affected (00:09:53): "due to whatever some outages, the reach could not complete the repair work yesterday." Used only to confirm the outage was real and dated; the public piece keeps the fault at the category level ("the AI services underneath the work"), never naming a provider as failing and never describing Reach as broken.

The story abstracts the outage to the category (an AI-services outage and the dependency it exposed). No provider is named as having failed. This is the author's own lived, dated experience (2026-09-03), stated as personal fact.

First-party - Reach get_results, this run (2026-09-04)

• meetingsBooked: 2 (sampleSize 2)
• qualifiedInterest: 10 (sampleSize 10)
• emailsObtained: 3 (sampleSize 3)
• positiveReplyRate: 0.2 on only 5 classified replies - flagged "Too few to conclude anything." Deliberately NOT used.
• Overall slice empty this run (people 0) because the account mirror is mid-recovery from the outage; byOpeningLine and byApproach returned empty, so no reply-rate table is claimed this run.
• Caveat, verbatim: "Reach sent 132 of 18586 outbound messages in this history - the rest were sent by hand on LinkedIn." Referenced only qualitatively ("more than eighteen thousand messages... almost all sent by hand") so the exact split used in the 2026-09-03 piece is not rebuilt.

Web - nothing cited

Searched warm-vs-cold / relationship-durability. Every result was a vendor SEO blog with no traceable primary source (Sopro, growleads, traxy, collectivei, gasimo, draftboard, salesmotion, launchleads). Floating figures ("warm converts 5-10x", "cold reply 1-5%", "58% of VC deals via networks") trace to nothing primary and are not cited, consistent with the 2026-08-20 / 2026-08-21 / 2026-08-26 precedent of resting on first-party when no clean primary exists.

House rules

• No real company named as struggling. No provider named as having failed.
• No price anywhere.
• No competitor named or recommended.
• POV: numbers (authority through the account's own real figures). Last used 2026-08-28, outside the 5-day window.
• Art direction: dusk-city (blue-hour city). Last used 2026-08-26, outside the recent window. The imagery runs dusk (the tower that went dark) -> the lights that stay on -> the lighthouse that waits -> dawn (the morning after).