Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →cell-architecture
These are two different layers of the architecture.
Passed 18 of 20 test cases with the skill, and 5 of 20 without it.
and 17 more in the full report
15 fixed5 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are building a new setup flow for an integration that only needs to interact with the control silo. Which webhook forwarding strategy should we use?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies setting the webhook forwarding strategy to CONTROL_ONLY | Missed | Passed |
The instructions your model reads when the skill loads.
Status: Active migration in progress. Migration-specific sections should be removed once complete, leaving a stable architecture reference.
These are two different layers of the architecture.
Cell — a self-contained Sentry deployment that owns a subset of organizations. Each cell
runs its own full stack — Getsentry, Snuba, Seer, Relay, Kafka, Symbolicator, and others —
on an isolated network with no direct cell-to-cell communication. OrganizationMapping.cell_name
records which cell an org lives in. See Paths Into a Cell for how cells
communicate with the outside world.
Locality — a named collection of cells, representing either a data residency zone (for
multi-tenant customers, e.g. "us", "de") or a dedicated deployment for a single customer
(e.g. s4s2). Multi-tenant customers choose a locality when creating an organization;
single-tenant localities are provisioned privately and not customer-selectable. Each locality
maps to a subdomain (us.sentry.io, de.sentry.io or s4s2.sentry.io).
Note: "region" is the old name for "cell". The codebase is actively being migrated. See Active Migration for details.
There are three high-level paths by which requests or data reach a cell.
{locality}.sentry.ioSynapse (getsentry/synapse) routes each request to
the correct getsentry cell within a locality, using an org to cell mapping it caches from control's
OrganizationMapping.
us.sentry.io -> Synapse (API proxy) -> US cell(s)
de.sentry.io -> Synapse (API proxy) -> DE cell(s)
s4s2.sentry.io -> S4S2 cell (single cell, no Synapse)
For Synapse to route a request, the URL must contain organization_id_or_slug. The canonical
test cases passed, vs 5 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.