Products · Foundry Early access

Manufacture realistic Service Bus traffic, on demand

Foundry is engineering-grade test data and load for Azure Service Bus. Seed realistic message floods, author JSON and XML payloads that actually validate, rehearse failure and dead-letter scenarios, and drive measured load against your own topics and queues - safely, and without a single stored secret. Shipping continuously: see what's new.

Manufacture realistic traffic - not lorem-ipsum noise

Point Foundry at a sandbox namespace and it produces the traffic your system actually meets in production: shaped messages, in the volumes you choose, into the queues and topics you name. It's the tooling we built to stress-test DLQ Manager itself - now yours.

Just need one message? A dedicated Send page fires a single live message - target, body, typed application properties - in seconds. The everyday "does this work? let me send one" is a two-field task.
When you need volume, Manufacture seeds anywhere from a handful of messages to a sustained flood, at the batch size and message size you specify.
Every message is composed from a template you control - real shapes, real application properties, randomised where it matters.
Target one queue, one subscription, or fan a run across an entire namespace in a single submission.
Watch it run live, follow it by id, and get an honest count of exactly what was sent.

The Send page: a target queue, a JSON or XML message body, and a typed application-property bag - one live message, sent — The Send page - one active message: a target, a body, and typed properties.

A template editor that treats your payloads as engineering artifacts

Test messages are only useful if they look like the real thing. Foundry's editor is built for that: JSON and XML as first-class formats, validated before they ever reach the broker, with randomisation targeted exactly where you want variety and nowhere you don't.

Schema-aware. Attach an XSD and the editor validates as you type, completes against your schema, and quick-fixes the common mistakes - the same intelligence your integrations get, on the messages that exercise them. Schemas are compiled securely and never fetch off the network.
Randomise by path. Click a value to get its exact path, then vary just that leaf - a fresh order id, a rotating region, a plausible amount - while everything else stays byte-exact.
Generate from your contract. Hand Foundry an XSD and it writes a valid starter document; hand it a sample and it infers a schema. Building a realistic message from a real contract takes minutes.
Generate the consumer too. Turn any JSON or XML message into a typed starter model in C#, Java or Rust - so the message you manufacture and the code that reads it never drift apart.
Honest about the wire. The editor shows the true encoded byte budget as you build, with typed application properties and per-property limits - a template that compiles is one that will actually send.

Screenshot coming here - the JSON/XML template editor with schema validation and randomisation

Rehearse dead-letter scenarios on purpose

You can't confidently operate dead-letters you've never seen. Foundry manufactures them deliberately - a controlled backlog of dead-lettered messages, with the fates and reasons you choose, so your alerting, your runbooks and your DLQ tooling get exercised before an incident does it for you.

Produce dead-letters with realistic, varied reasons - or drive messages to the dead-letter queue by exceeding delivery counts, the way production does.
Deterministic fates mean a rehearsal is repeatable: the same seed produces the same mess, every time.
The perfect companion to DLQ Manager - manufacture the scenario in Foundry, then practise resolving it next door.

Screenshot coming here - manufacturing a controlled dead-letter backlog

Stand up a topology, tear it down cleanly

Realistic tests need realistic topology. Foundry creates the queues, topics and subscriptions a scenario calls for, runs to convergence idempotently, and - when you're done - removes exactly what it made, with the kind of safety a destructive operation deserves.

Declarative topology that converges: creating something that exists is a no-op, so a run is safe to repeat.
Cleanup binds to what was approved. A teardown re-discovers and re-hashes the target set and refuses if anything drifted - it deletes precisely the entities you reviewed, and nothing else.
Every destructive action is gated by an audit ledger and a typed confirmation that names the namespace - the safe default is to stop.

Your messages stay in your Azure region; access is granted - and revoked - entirely in your tenant.

Runs that survive the browser, the network and a restart

A submitted run is a durable job, not a foreground task. Close the tab, lose the connection, redeploy the service mid-run - the work keeps going, and a reconciler adopts and finishes anything that was in flight when a process died. You start the work and walk away; the platform is responsible for finishing it.

Every run is addressable by id and followable to a terminal state - completed, partial, failed or cancelled.
A durable claim with fencing means a resumed run never re-sends a range the previous owner already claimed.
Interrupted runs resume automatically after a regional outage or a deploy - waiting, not losing.

Drive measured load - and get numbers back

Foundry doesn't just make messages; it makes pressure. Point a measured load run at your own topics and queues and see how your consumers, your autoscale and your dashboards behave under a sustained, shaped flood - the same way we baseline our own platform.

Choose the concurrency, duration, batch size and message size, and hold the load steady while you watch the system react.
A repeatable pass/fail scorecard turns "can it take the traffic?" into an answer with p95 latencies and throughput, not a shrug.
Per-account caps keep a load rehearsal inside its lane - it manufactures traffic into a sandbox you're happy to fill, never a runaway.

Screenshot coming here - a measured load run with a latency scorecard

Send and Lab modes - production-safe by default

A tool that can manufacture and delete traffic must never do so by accident. Foundry separates the two intents at the connection: Send mode can only add messages and is safe to point anywhere; Lab mode - the only mode that can create or delete entities - is a deliberate choice, gated by role, and only ever pointed at a disposable sandbox.

A Send connection physically cannot reach the destructive operations - it's a boundary, not a warning.
Destructive work fails closed: without its audit ledger and cooling-off in place, it refuses to run.
Mass deletion demands a typed confirmation that names the namespace, and every entity removed is written to an immutable audit record.

Delivery it will tell you the truth about

Honest test tooling doesn't over-promise. Foundry states exactly what it guarantees: at most one send attempt per claimed range, with any genuinely-unknowable outcome reported rather than hidden. You get a real count of confirmed, failed and unknown - never a comforting number that isn't true.

Duplicates are possible and are reported, not swept under a green checkmark - both are properties of messaging, stated plainly.
An "unknown" outcome is surfaced in its own column, so you always know the difference between "sent" and "we cannot be sure."
The full delivery contract is written down - because a sandbox that quietly implied exactly-once would be trusted for something it can't support.

Passwordless, cross-tenant, and isolated end to end

Connect a Service Bus via Entra ID RBAC - including into a customer's own tenant through a secretless, federated workload identity. Foundry never sees, asks for or stores a connection string. A least-privilege SAS path remains for break-glass and local development, and the root shared-access key is refused outright.

Access is a role assignment in your tenant - granted in minutes, revoked instantly, with nothing to rotate, vault or leak.
Cross-tenant onboarding is proven against real Azure: a live acceptance run confirms the token exchange works, a send-only grant is refused management operations, and a revoked grant stops the next run cold.
Multi-tenant by construction - each organisation's data is isolated end to end, demonstrated by a deployed two-tenant acceptance matrix, not merely asserted.
Foundry's own deployment holds no shared-key secret anywhere: identity all the way down.

A real API - Foundry fits into your pipeline

Everything the console does, an API does too: a versioned, contract-first surface for accepting and following durable runs, with a generated client kept honest against the contract by an automated check. Seed a scenario from CI, drive load from a pipeline step, and follow a run to completion from a script.

Contract-first and versioned - the version a caller compiled against is the version they get.
Idempotent submission: a retried request returns the run you meant, never a duplicate or the wrong one.
Bearer-authenticated and tenant-scoped, on the same isolation and rate-limiting as the console.

Screenshot coming here - driving a durable run from CI via the API

Per-account controls and a complete audit trail

A platform that manufactures traffic into shared infrastructure needs real guardrails. Foundry gives every account finite, enforced limits and a support-controlled stop - and records the actions that matter.

Per-account caps on concurrent runs, seats and messages per day - metered accurately and settled exactly once, so the numbers are billable, not just advisory.
A namespace allowlist and per-tenant entitlements decide what each account may point at - enforced on every connect and every run.
A support-controlled kill switch can pause a single account or the whole platform instantly.
Destructive operations and credential lifecycle are written to an immutable audit trail that survives even offboarding.

Screenshot coming here - per-account caps, entitlements and the kill switch

Point it at your own namespace.

The tour is nice; a realistic flood into your own sandbox is nicer. Foundry connects with Entra RBAC and manufactures traffic in minutes - no stored secrets, safe by default.

Start free - continue with Microsoft Compare with Azure Monitor