I Pulled 90 Days of Incidents From All 20 Vendors in My Stack. 1,765 Records. Four Vendors Don't Publish a Feed.

TL;DR: On 2026-08-15 I fetched the public status feed for all 20 vendors a one-person company typically runs on and counted 1,765 incident records opened in the trailing 90 days across the 13 vendors that let me retrieve a clean 90-day window. Four vendors (Notion, Linear, Calendly, Intercom) publish no machine-readable feed at all, and three more (OpenAI, Zapier, Cloudflare) publish one that runs out before day 90. So the honest answer to what a solo operator does when a vendor goes down is that you cannot measure your own aggregate exposure from the outside, and the workable plan is per-vendor: know which of your dependencies can fail without telling you, and keep those off the path between you and getting paid.

A company with people has a vendor manager. I have a browser with 20 tabs, and nobody publishes the number I actually want, which is how often the whole stack breaks. Status pages are built to be read one at a time, by one customer, about one product. Nobody adds them up. So I did.

What did I actually fetch?

I took 20 vendors that show up in more or less every solo stack: OpenAI, Anthropic, Cursor, GitHub, Vercel, Stripe, Zapier, HubSpot, Slack, Notion, Linear, Figma, Airtable, Cloudflare, Supabase, Netlify, Twilio, Sentry, Calendly and Intercom. For each I requested {status-host}/api/v2/incidents.json, the Statuspage convention, then counted records with a created_at inside the trailing 90 days (2026-05-17 to 2026-08-15).

Two things nearly made this post false, and both are worth stealing.

The first is redirects. Anthropic's status page has moved to status.claude.com, and status.anthropic.com now answers with a 301. A fetch that does not follow it returns the redirect body, which parses to zero incidents. Run without -L and you would publish "Anthropic reported no incidents in 90 days." The real figure is 135 records. Always use curl -L.

The second is that a naive count of created_at occurrences in the raw JSON counts every status update, not every incident. Vendors post between one and roughly a dozen updates per incident, so that method inflates the number four to six times over. Across the feeds I pulled there were 2,540 update timestamps sitting inside 645 incident records.

There is also a cap. /api/v2/incidents.json returns the 50 most recent records (25 for OpenAI and Zapier), and for the busier vendors that runs out long before 90 days: Twilio's 50 records cover 17 days, Cloudflare's cover 19, OpenAI's 23, Anthropic's 31. The uncapped source is history.json?page=N, which returns three months per page and goes back years. Where the two overlap they agree exactly, which is how I know the pagination is not lying to me.

What did the feeds say?

Sixteen of 20 vendors serve a machine-readable incident feed. Thirteen of those let me retrieve a clean trailing-90-day window, and those 13 opened 1,765 incident records between 2026-05-17 and 2026-08-15:

Vendor	Incident records, 90d	Published components
Twilio	932	191
Stripe	385	6
Anthropic	135	6
GitHub	73	12
Cursor	64	6
Supabase	58	28
Vercel	35	64
Sentry	30	43
Slack	21	n/a
Netlify	16	40
HubSpot	10	11
Figma	3	17
Airtable	3	1

Twelve of the 12 Statuspage vendors whose history.json parsed also set show_uptime_calendar: true, so uptime history is the one thing this group is genuinely good at publishing, though publishing it and getting it right are separate questions: 11 of the 15 AI vendors that print an uptime percentage print one their own incident log cannot account for.

Why is 1,765 not a reliability ranking?

Because incident records are not outages, and the vendors are not counting the same object. Twilio publishes 191 separate components and opens records against them individually, which is why it accounts for more than half the total on its own. Airtable publishes one component. Reading that as "Twilio broke 310 times more than Airtable" is a category error: it mostly says Twilio instruments SMS delivery per country and Airtable instruments "Airtable."

I am reporting incident records, and I am saying so in the same sentence on purpose. There is no cross-vendor normalization available here, and anyone who builds a league table out of these feeds is publishing their own component taxonomy, not a reliability finding. The number that matters to a solo operator is not per-vendor anyway. It is that something in the stack opened a record roughly 20 times a day, every day, for 90 days.

Which vendors can you not count at all?

Four. Notion, Linear, Calendly and Intercom return HTML at /api/v2/incidents.json, at /summary.json and at /history.json. That is "no machine-readable feed," and it is emphatically not "no incidents." Their pages exist and work fine for a human reading one at a time. They simply cannot be counted.

All six of the pages that failed the Statuspage history API (those four plus OpenAI and Zapier) are served from the same Vercel deployment id, dpl_2bnbifZmJC1M7XQQ5G3kSR2V9UUF. One hosted status-page product, one migration, six vendors, and only two of them turned on the compatibility endpoint. OpenAI, Zapier and Cloudflare serve incidents but no retrievable history, so their 90-day totals are floors I cannot close.

Stripe is its own puzzle. status.stripe.com/api/v2/incidents.json 404s; the real feed lives at www.stripestatus.com. And status.stripe.com/current still returns valid JSON stamped "time":"February 09, 2024 @ 06:08PM +00:00", a live endpoint reporting a timestamp from two and a half years ago.

So what does a one-person company actually do?

Not redundancy. Running two CRMs is not resilience, it is two CRMs. What the count actually argues for is triage, because the vendors sort cleanly into three groups and only one of them needs work.

Vendors with a countable feed can be monitored: subscribe to the feed, not the marketing email, and let it page you. Vendors with no feed (the four above) cannot be monitored from outside, so they must not sit between you and revenue. If Calendly is the only way a prospect can book you, its silence is your outage. Give it a fallback that is a plain link to a plain page you control.

The third group is the one that gets people: vendors whose failure you inherit without a status page of your own to point at. This is the $1,400-a-month stack problem in a different shape. Your customers do not care whose incident it was. It is also why the exit question matters more than the uptime question, and whether you can get your data out is the audit I would run first.

What does this not prove?

It does not prove any of these vendors is unreliable. Record counts measure how granularly a company instruments itself, and the most transparent vendors score worst by construction. It does not prove 1,765 records meant 1,765 minutes of pain for anyone; most were scoped to components a given customer never touches. And it is a 90-day snapshot taken on one day, which a re-run next quarter would move.

What it does establish is the structural thing. A one-person company carries 20 vendor relationships with no vendor manager, no contractual leverage, and, for a fifth of them, no machine-readable way to know they are down. Supabase's uptime SLA is explicit that it "will apply to the Services for Enterprise Customers specified in an Order Form", which is the normal shape of these documents and not a criticism of Supabase. On a self-serve plan you are not a party to an SLA. You are a reader of a status page, and four of your vendors do not let you read theirs with a script. There is often nobody to write to either: 5 of 25 AI vendors publish a support address a buyer can see before paying. That is the actual answer, and it is why the receipts on solo AI companies keep landing on distribution and operations rather than on tooling.