About

Glad you’re curious. Here’s the short version, then everything else.

What it is

Endpoints that misbehave on purpose.

catastrophic.io is a free, public collection of HTTP endpoints that deliberately return wrong, late, malformed, or contradictory responses. You point a client at one and watch how it handles the network reality that production will eventually serve up — a 503 with a lying Retry-After, a JSON body that promises one schema and delivers another, a stream that ends mid-object, a robots.txt full of plausible-looking nonsense.

It is not a service. It is a target.

The four-host model

The site is one edge function dispatching by hostname:

• catastrophic.io — the hub. Catalog, playground, this page, the docs, and the /tools/ cluster (/ip, /headers, /connection, /locale, /encoding, /fingerprint, /profile) that shows you what your client looks like to a server before you point it at the chaos. No chaos endpoints here.
• chaos.catastrophic.io — the chaos endpoints. HTTP responses that deliberately misbehave.
• not.catastrophic.io — the validation layer. A well-formed counterpart for every chaotic endpoint on the platform, including the ones served from bots., paired by path. Also home to /infinite/, a wildcard catch-all that serves deterministic, schema-stable JSON or HTML for any path of any depth — an unbounded URL space for stressing crawlers, caches, link checkers, and training pipelines.
• bots.catastrophic.io — chaotic versions of canonical well-known files: robots.txt, llms.txt, sitemap.xml, /.well-known/security.txt, AASA, assetlinks, and so on.

The split exists because the chaos and its counterpart need to be addressable independently. You build against not. until your client works, then change the hostname to chaos. or bots. to see how it handles the same paths gone wrong. Same routes, same payloads, opposite behavior.

The flip-hostname workflow

Develop against not.catastrophic.io. When the happy path works, flip the hostname to chaos. or bots. and run the same code. The path is identical; what comes back is not. The X-Chaos-* response headers tell you which mode the endpoint chose.

What it hardens

Every HTTP client has a stack of layers. At the bottom: bytes arrive, do they parse? Above that: does the structure match a schema? Above that: does the data make sense for the domain? catastrophic.io hardens the bottom layer hard, the middle layer indirectly, and the top layer not at all.

The bottom layer doesn’t care about your schema. It cares whether your client copes with a 503 carrying a lying Retry-After, a JSON body that ends mid-object, a Content-Type: application/json whose body is HTML, a chunked stream that closes early, a Set-Cookie no browser will accept. Every client has to handle these regardless of what schema sits on top, and most do it badly. That’s the bug that ships: “our integration crashed because the upstream returned malformed JSON exactly once during the retry.”

For schema-shaped chaos, two design choices bridge part of the gap. The flip-hostname workflow means /json on chaos. returns a body structurally similar to /json on not. — same outer shape, same field names — until it isn’t. And every chaos endpoint has an OpenAPI entry describing its modes, so the chaos is schema-driven adversity, not random garbage.

For domain-specific shape problems — your own User resource missing a required field, say — there’s the playground’s Custom tab. Upload a JSON Schema and you get a pair of temporary endpoints: a not. URL that serves valid examples against your schema, and a chaos. URL that serves the same examples with one targeted mutation (dropped required field, type shift, extra unknown field, enum violation, format violation). The flip-hostname workflow then works against your own contract. For longer-lived contract tests, write them against your own OpenAPI mock or use a tool like Pact. See also for adjacent tools.

Who it’s for

• HTTP client authors
• SDK maintainers
• Parser and decoder writers (JSON, XML, CSV, JSONL, OOXML, PDF, ZIP, SVG, HTML)
• Agent builders wiring LLMs into network tools
• Anyone shipping software that consumes HTTP responses written by someone else

What it is not

• Not a load tester. Sixty requests per minute per IP, hard ceiling.
• Not a fuzzer. The chaos is curated and labeled, not random.
• Not a security scanner. Try public-firing-range for that.
• Not a mock server you self-host. The point is the shared public surface; there’s no install path.
• Not a proxy. Don’t route third-party traffic through it.

Privacy

No tracking. No cookies. No logged bodies, headers, or query parameters. The privacy page has the full statement.

Cost and availability

Free. No signup, no API key, no account. Rate limited at 60 requests per minute per IP per host. No SLA — endpoints can be slow, change, or be unavailable without warning. That is, in a sense, the product.

Stability

Endpoints can be added, renamed, or have their modes reshaped without notice. The OpenAPI specs are the closest thing to a contract; the response headers are the runtime contract. Pin to X-Chaos-* headers, not to body shapes you observed once.

The site has never been formally launched. Breaking changes are still fair game.

Origin

Built by someone who got tired of writing the same chaos handlers in every test suite. The endpoints started as a personal collection, then turned out to be useful to other people, then grew.

Where next

• Catalog — every endpoint across chaos, not, and bots
• Playground — try endpoints in the browser
• Docs — how to use it from code, from agents, and at the protocol level