Reference · regions
Six ingest points. Data stays in the one you pick.
An account belongs to exactly one region from the moment it is created. Every byte that account sends is terminated, written, indexed, replicated, queried, alerted on and eventually deleted inside that region. There is no background replication to anywhere else and no operational path that would produce one.
Ingest point register
| Region | Jurisdiction | Accept ceiling | Retention ceiling | Live since | State | |
|---|---|---|---|---|---|---|
| eu-north-1 | EU / EEA | 1 200 000 ev/s | 400 d | 2021-03 | accepting | |
| eu-central-1 | EU / EEA | 900 000 ev/s | 400 d | 2022-06 | accepting | |
| eu-west-1 | EU / EEA | 700 000 ev/s | 400 d | 2023-02 | accepting | |
| na-east-1 | North America | 1 100 000 ev/s | 400 d | 2022-01 | accepting | |
| ap-southeast-1 | Asia-Pacific | 600 000 ev/s | 400 d | 2024-04 | accepting | |
| sa-east-1 | South America | 250 000 ev/s | 400 d | 2025-09 | accepting | |
| 6 regions | 4 jurisdictions | — | 4 750 000 ev/s | 400 d | — | — |
The query host of a region is query.<region-label>.halkon.sbs and the console is app.<region-label>.halkon.sbs. They are separate names so you can firewall read access separately from write access.
Current load and headroom
| Region | Agents | Share of ingest | Stored | Now |
|---|---|---|---|---|
| eu-north-1 | 15 900 | 27.1% | 402 TB | —k |
| eu-central-1 | 12 100 | 20.8% | 291 TB | —k |
| eu-west-1 | 8 550 | 14.7% | 206 TB | —k |
| na-east-1 | 14 100 | 24.2% | 339 TB | —k |
| ap-southeast-1 | 5 410 | 9.3% | 108 TB | —k |
| sa-east-1 | 2 140 | 3.9% | 54 TB | —k |
| total | 58 200 | 100% | 1 400 TB | —k |
The “now” column is thousands of events per second, computed in your browser from the published daily profile and the current clock. It is an illustration of the shape, not a live feed.
Why there is no global endpoint
A single anycast name would be convenient and would quietly defeat the point of the product. If one hostname can land in any region, then the region your data is in becomes a routing accident, and no data-residency statement survives that.
So the hostname carries the region, the key is scoped to the region, and a key presented at the wrong ingest point returns 403 naming the scope it needed. Misdirected data is refused, not silently re-homed.
The second reason: distance is expensive
Long-lived streams magnify round-trip time. With four batches in flight and a 240 ms round trip, a single agent tops out around 16 000 events per second regardless of how much bandwidth it has. Locally it does not hit a wall until the ingest point does.
| Agent located in | Nearest point | RTT p50 | Farthest point | RTT p50 |
|---|---|---|---|---|
| Northern Europe | eu-north-1 | 9 ms | ap-southeast-1 | 214 ms |
| Central Europe | eu-central-1 | 11 ms | sa-east-1 | 196 ms |
| Western Europe | eu-west-1 | 8 ms | ap-southeast-1 | 231 ms |
| Eastern North America | na-east-1 | 12 ms | ap-southeast-1 | 242 ms |
| South-East Asia | ap-southeast-1 | 14 ms | eu-north-1 | 214 ms |
| South America | sa-east-1 | 16 ms | ap-southeast-1 | 278 ms |
You are paying for it twice: in agent throughput and in a legal position that is harder to describe than it needs to be. Moving an account to a nearer region is a new account, a key swap and an agent config change — we do not migrate the old data across the boundary, which is the whole point.
What crosses a region boundary
A short list, stated precisely, because “your data never leaves” is a claim that deserves an itemised answer rather than a slogan.
| Item | Leaves the region? | Detail |
|---|---|---|
| Events, logs, metrics, traces | never | Written, indexed, replicated and deleted in-region. Three copies, separate racks, one region. |
| Query results | never | Executed in-region; the result travels only to the client that asked for it. |
| Alert payloads | never | Delivered from the region’s own egress to the destination you configured. |
| Backups and snapshots | never | In-region object storage. There is no cross-region disaster-recovery copy, on purpose. |
| Support access to your data | never | Engineers reach a region’s data plane only from within that region, under a time-boxed grant you approve. |
| Alert rule and dashboard definitions | never | Stored with the account, in-region. |
| Account identity and key hashes | replicated | Hashes only, to the regions the account is pinned to. Never to a region you do not use. |
| Daily accepted-byte totals | yes | Counters — a date, a region, a signal type and a number. No content, no attributes, no identifiers. |
| Invoices and contract records | yes | Held at the registered office in Warsaw, Poland, as company law requires. |
The last two rows are the complete list of things that move. Both are described in the data-residency clause, which is contractual rather than a description of current practice.
Picking a region
Legal constraint first
If a regulator, a contract or an internal policy names a jurisdiction, that decides it. Latency is a performance problem; jurisdiction is a compliance problem, and only one of the two can be fixed later.
Then where the hosts are
Pick the point nearest the bulk of your fleet, not nearest your office. A dashboard user tolerates 200 ms; an agent holding four batches in flight does not.
Split rather than stretch
A fleet on two continents wants two accounts, one per region, each querying its own data. On the Regional plan they sit under one contract and one invoice while staying separate stores.
We open a new ingest point when committed demand in a jurisdiction passes roughly 120 000 events per second and there is a legal reason the existing points cannot serve it. Two candidates are under evaluation; neither has a date, and we do not announce regions before they accept traffic.