Plans, limits, and retention
Understand the current plan catalog, usage meters, history windows and work limits.
On this page
Anectico measures usage in units a developer can connect to application behavior. Seats are not a usage meter.
The table below is the current self-serve catalog. An early-access agreement or the Console may
show different effective limits. Billing and usage in
the Console, or anectico usage, is the source of truth for an active organization.
Self-serve limits
| Plan | Pooled events / month | Active metric series | Replay sessions / month | Retention | Projects | Agent audit history | Daily decision-scoring cap |
|---|---|---|---|---|---|---|---|
| Free | 1 million | 1,000 | 100 | 7 days | 1 | 30 days | $0.10 / day |
| Solo | 10 million | 10,000 | 10,000 | 30 days | 10 | 30 days | $0.50 / day |
| Pro | 150 million | 50,000 | 50,000 | 90 days | 50 | 90 days | $2 / day |
| Scale | 500 million | 100,000 | 250,000 | 180 days | 1,000 | 180 days | $10 / day |
Plans differ by volume and history. Agent access through MCP and the CLI is included on every plan, and you bring your own model: Anectico does not run an investigation for you on any plan. See agent plan headroom for the separate provisional OAuth approval and automated-work allowances, and agent budgets for owner-set operation and typed-decision spend controls.
API request rate
Every plan also has a request rate: how many API requests per second your management keys may send, and how many at once (the burst). It counts requests to the REST API and to MCP, not accepted work, and is separate from the operation budgets.
| Plan | Requests per second | Burst |
|---|---|---|
| Free | 10 | 20 |
| Solo | 50 | 100 |
| Pro | 100 | 200 |
| Scale | 500 | 1,000 |
Each management key has its own allowance, so one busy key does not slow another, even when the same person created both. All of your workspace's management keys, across projects, are also counted together against one workspace allowance at the plan's rate, so creating more keys does not multiply it. A person signed in to the Console, or an agent connected over OAuth, has the person's own allowance. An owner can lower the rate per key, as a default for keys, or for the whole workspace, never above the plan; after a downgrade a value above the new plan is not applied. The request rate is an operational limit, not billing: reading the API does not use your event allowance, and no price depends on it. See Manage agent budgets.
Agent activity and proof-page opens follow the audit-history window above. A downgrade immediately shortens what can be read; older records are removed on the next retention pass. An upgrade widens the window but never restores deleted records.
The daily decision-scoring cap bounds the small typed judgments Anectico makes on your behalf on
every plan. Today there are four made on your behalf — ranking anomaly findings,
suggesting a category and an attention marker for the repeated
log templates you look at, saying which declared name an
observed-but-undeclared tracking-plan event name or
property key was most likely meant to be, and judging how serious each
Issue you look at is right now and which part of your application
it comes from — plus any
decision-score evaluators you configure. One judgment costs a fraction of a
cent, so your plan's event and series meters are the real allowance and this cap only stops a
runaway. When it is reached nothing is refused: findings simply stay unranked, log templates are
listed without labels, tracking-plan suggestions stay pending, issue judgments stay pending, and
decision-score evaluations are not scored — a sampled check waits to be retried, and an on-demand
evaluation answers 429 saying nothing was scored — until the cap resets at midnight UTC. Everything
else works exactly as before. The same holds whenever the scoring model is unavailable, except that
an on-demand evaluation then answers 503 (or 400 when typed evaluation is not available at all).
Anectico does not translate a plain-language question into a query. Your own agent writes the query, or the read-only SQL, with its own model and runs it through the same tools you would.
Current prices and included product capabilities are listed on the pricing page.
Conditional reads still use request allowance
Authorized conditional reads of a saved insight definition or ready analytics result may return
bodyless 304. These requests still use the key and workspace request allowances and keep the
applicable rate and checked headers. They start no measurement and use no accepted-query budget.
Stored payload reads, permission and lifecycle checks, source verification and public JSON
serialization still occur. See conditional reads
for accepted validators, private revalidation, lifecycle states and your cache-disposal duties.
What counts as an event
Product events and technical events (logs and spans, including error signals) draw from separately configured allocations within the organization's pooled allowance. Each newly admitted logical event reserves one unit in its family in the UTC month of its original server admission. A critical error is included in technical events, with a separate critical-error count; identity controls and metric points have their own visible counts and do not consume either event allocation. The general pooled-events summary is the sum of admitted product and technical events, not a second charge.
The agent-run events Anectico emits for you — $agent_run_started, $agent_run_finished and
$agent_tool_failed — are ordinary product events and consume the configured product allocation.
They are counted once, as events: the
agent metrics in your dashboards are a separate meter (active series) over the same underlying
signal, and the two are never charged for the same row twice.
Metrics use active series because their cost depends on the number of distinct label combinations, not only the number of data points. At the active-series limit, existing series continue to ingest; only unseen metric names or label combinations are rejected. This rejection is non-retryable. The meter is organization-wide and its background snapshot may lag by a few minutes. Replays count recording sessions that started in the period.
Which month usage lands in
Usage is counted in the period of its original server admission, not the timestamp on the data. If your SDK buffers events offline and sends them later — a mobile app reconnecting after a flight — those events are counted in the month they first reach us, even though they keep their original timestamps everywhere you read them. Backdating a timestamp therefore does not move usage into an earlier period, and it never removes usage from the current one.
Projects
Each plan allows a fixed number of projects: 1 on Free, 10 on Solo, 50 on Pro and 1000 on Scale. Creating one beyond the limit is refused; upgrade to raise it.
Downgrading never deletes a project. If a downgrade leaves you above the new limit, everything keeps working and you simply cannot create another until you are back under it.
Deleting data changes one meter, not the other
Deleting a metric frees active-series capacity. Active series measures what you are currently tracking, so a metric you delete stops counting against the limit once the next background snapshot runs; that is why removing an accidental high-cardinality metric is the remedy when you are near the cap. The freed capacity is real capacity: new series are admitted against it from that same snapshot, not only at the start of the next monthly period. A series reserved immediately before a snapshot can be held through one additional snapshot interval so an in-flight data point from another project is not mistaken for deleted data.
A deleted metric that your application keeps sending stays deleted, and stays free. Its data points are still hidden from every query, dashboard, and alert, and they do not count toward your active series or take capacity from a new one — so you do not have to redeploy before the capacity comes back. Deletion suppression is project-scoped: the same series sent by a different project remains active and is admitted normally. If you want the deleted project's metric again, send it under a name you have not deleted.
Deleting logs, spans, errors, or product events does not refund their admission counts. That meter counts what was admitted during the period, so retention expiry or deletion cannot return capacity. Project deletion preserves the organization's monthly usage; organization erasure removes its counters. Delete for privacy, correction, or hygiene — not to recover event capacity. Replay sessions behave the same way.
Retention
Retention is a rolling history window. Data outside the plan's window is no longer available to search, timelines, API reads, or MCP tools.
Product and technical history start at midnight UTC, the configured number of days before today. For example, seven-day history on October 6 includes events from September 29 at 00:00 UTC onward; that entire oldest day remains available until midnight UTC on October 7. An event received late within that window uses its occurrence time, so a 167-hour-old event remains readable. A previous shortening can set a later starting point.
The window is organization-wide. Every project inherits the organization's current plan or administrative override; projects cannot advertise or configure a separate retention period.
If the window is shortened, older history expires under the new limit. Increasing it later keeps the history that is still available for longer, but it does not bring back history that already expired under the earlier window. There is no archive or recovery of expired history.
Read coverage
See Read coverage and intake completeness for requested and effective windows, retention floors, empty-result interpretation and intake settlement. A readable window does not certify complete upstream capture.
Family policy configuration
The family policy API records product and technical retention choices within separately granted ceilings (seven to 365 days maximum) and allocations within the existing pooled events allowance. Every organization starts with a default derived from its plan: ceilings equal the plan's retention, the pool equals its monthly events allowance, and the choice keeps full retention with 20% of the pool for product events. Every project reads the same organization policy and pool. Only Anectico can grant a ceiling or increase the allowance. Customer updates require both current revisions and organization-wide settings authority.
Retry receipts are retained for seven days, up to 1,000 unexpired receipts per organization; new mutations refuse at that bound while existing retries remain readable. Keys are 1–128 UTF-8 bytes. These are policy-update retry receipts, separate from event-admission records. Family policy never extends replay or other content policy.
Product capture admission
POST /api/v1/capture and internal agent-run events use the product allocation. Each new
product event is admitted whole while the organization's product count for the month is below
125% of that allocation, and refused with quota_exceeded at or above that threshold; zero
allocation refuses new product events. The decision is per event, so the rest of a batch is
still decided normally. Technical traffic cannot consume this capacity. Identity controls
(identify and $groupidentify) are admitted through product exhaustion and counted separately.
The only policy refusal is an organization whose allocations still need to be chosen (for
example after an entitlement change). Capture then refuses the whole request with retryable
503 dependency_unavailable; OTLP HTTP returns retryable 503 and OTLP gRPC Unavailable.
A usage measurement that has not refreshed recently, or the start of a new month, never refuses
intake. Admission decisions use counts that can lag other intake servers by a few seconds, so an
allocation is a threshold, not an exact spending ceiling.
Repeating the same message_id with the same normalized payload in the same project within
seven days is recognized as a retry: it keeps its original timestamp when you omit it, is not
counted again, and is still acknowledged even after exhaustion. Reusing a message_id with a
different payload refuses that event alone as invalid_event. Keep IDs, payloads and explicit
timestamps unchanged; see capture retries.
Counts measure admission, not confirmed storage, and uncertain queue delivery keeps the count.
GET /api/v1/usage/families, anectico usage families, MCP get_family_usage, and Billing and
usage in the Console show the month's admission counts and INDEPENDENT enforcement. The counts are a snapshot as of
observed_at (refreshed every few minutes); revision identifies the snapshot. A missing
measurement means unknown, not zero, while a present measurement with zero counts means measured
zero. Counts measure admission, not confirmed storage or complete source coverage. Retention,
project deletion, and exact retries do not refund or multiply them. The allocation permits
documented overage, so it is not an exact spending ceiling.
Technical OTLP admission
OTLP logs and spans use the technical allocation independently of product capture. Ordinary logs
and spans follow the configured sampling ladder as their family's count rises; at zero allocation
they are refused. Critical error signals continue to be admitted through technical exhaustion and
are included in technical_events, critical_errors, and, when admitted at or above the allocation,
critical_error_overage. Metrics use the separate active-series gate and appear as metric_points.
Sampling is reported as OTLP partial success; exporters must not resubmit sampled positions.
Positions are counted once they are published. OTLP has no required client retry identity, so
sending the same export again creates new positions and can consume more capacity. A publish
failure returns retryable 503 (HTTP) or Unavailable (gRPC) and is not counted; follow the
exporter's normal retry guidance, which may deliver part of the batch twice. A successful
response or partial success is final for that submission.
Field limits
These apply to every plan and are not usage meters. They bound one payload rather than a month's volume, so a request that trips one is rejected immediately and is not retryable without a change.
| Field | Limit |
|---|---|
| Metric name | 255 characters |
| Span name | 255 characters |
| Attribute key | 512 bytes |
| Attribute value | 32,768 bytes |
| Attribute value nesting depth | 8 levels |
distinct_id |
200 bytes |
| Distinct IDs in one recording lookup | 100 |
| Matchers in one alert silence | 32 |
| Alert-silence matcher label name | 512 bytes |
| Alert-silence matcher value | 4,096 bytes |
| Stack frames symbolicated for one request or occurrence | 256 |
| Event name (product events) | 200 UTF-8 bytes |
| Attributes per span, span link, log record, data point, or exemplar | 256 |
| Total attribute bytes per span, log record, or data point | 262,144 bytes |
| Spans, log records, or data points per export request | 10,000 |
For OTLP attributes, the attribute value limit uses the following byte accounting, applied recursively to arrays and nested key-value lists. This is the receiver's size budget, independent of whether the export uses JSON or protobuf; it is not the serialized request length.
| Value type | Bytes charged |
|---|---|
| String | UTF-8 byte length |
| Byte string | Raw byte length, before any base64 encoding |
| Integer, floating-point number, boolean, or empty value | 8 bytes |
| Array | Sum of each element's charged size, plus 1 byte per element |
| Key-value list | Sum of each key's UTF-8 byte length and its value's charged size, plus 2 bytes per entry |
The container accounting applies at every nesting level, including elements whose values are empty strings or empty containers. For example:
| Attribute value | Charged size | Within the 32,768-byte value limit? |
|---|---|---|
| One 32,768-byte string | 32,768 bytes | Yes |
| Array of 1,000 strings, each 31 bytes | 1,000 × (31 + 1) = 32,000 bytes | Yes |
| Array of 1,000 strings, each 32 bytes | 1,000 × (32 + 1) = 33,000 bytes | No |
| Array of 1,024 strings, each 31 bytes | 1,024 × (31 + 1) = 32,768 bytes | Yes |
| Array of 1,024 strings, each 32 bytes | 1,024 × (32 + 1) = 33,792 bytes | No |
Exactly 32,768 charged bytes is allowed; the other field, nesting and per-item limits still apply.
Each distinct ID in a recording lookup is also subject to the 200-byte distinct_id limit above.
Alert-silence regular expressions use the matcher-value limit and are validated when the silence is
created or edited; a malformed expression is rejected instead of creating a silence that can never
match.
The total attribute bytes limit sums each attribute key's UTF-8 byte length and its value's charged size for one item, because one item is stored as one record. For a span that is its own attributes plus every span link's and every span event's; for a log record it is the body plus the attributes; for a metric data point it is the point's attributes plus its exemplars'. Individually legal attributes can add up past this, and an item that does is rejected. It is set well above ordinary instrumentation — a span carrying eight maximum-size exception stack traces still fits — so reaching it usually means an application is attaching a whole request or response body to a span. Attach a reference instead, or truncate before the attribute is set.
Metric and span names follow the OpenTelemetry maximum instrument-name length of 255 characters. Names are otherwise accepted as your instrumentation emits them, including forms OpenTelemetry does not itself recommend — a leading digit, a colon (as Prometheus recording rules use), spaces, and non-ASCII letters all work.
What a name may not contain is characters a reader cannot see: control characters, bidirectional overrides, zero-width and invisible characters, and variation selectors. These have no legitimate use in a name, and a name carrying them would display as something other than what it is wherever it is read — on a proof page, in a search result, or by an agent reading it through the API.
An export rejected by OTLP field validation names the field category and the rule. For example,
attributes: attribute value exceeds 32768 bytes identifies the value limit without naming the
submitted attribute key. HTTP returns status 400 with this message; gRPC returns InvalidArgument
with the same message. Submitted names, keys, identifiers and values are not echoed back, so compare
your payload against the limits above. Malformed payloads and unclassified validation failures use
a generic rejection message instead of exposing parser or internal error details.
OTLP admission validates individual items and batch limits; it does not check the complete trace
graph for cycles. Parents and linked spans can arrive in separate exports or be outside the
retained data. An accepted export therefore does not certify an acyclic graph. Cycles found by
critical-path analysis are reported through has_cycle; see
trace and unified search.
One invalid item rejects the whole export request. If a single metric in a batch carries an invalid name, the batch is refused rather than partially accepted, so nothing is silently dropped. Fix the name and resend.
Gauge, sum, explicit-histogram and summary metrics are accepted. Exponential histograms are rejected as unsupported metric data; configure the exporter to send explicit histograms before resending. Summary counts and quantile values are stored as measurements and do not replace exporter labels or create a new series whenever the observed values change.
Span start and end times, span-event times, metric observation times and exemplar times must be present
and fit the storage timestamp range. A metric's optional start time cannot follow its observation
time. Numeric observations must be present and finite; summary quantiles must be between zero and
one. These checks happen before delivery is acknowledged. OTLP NoRecordedValue markers are
accepted and count toward request limits; their timestamps and attributes are validated, while
their unused measurement fields are ignored. They produce no measurement row or persistent
staleness tombstone, so earlier measurements remain available in historical queries. Logs use
their source timestamp when present and otherwise their observed timestamp; at least one valid
time is required.
Span events on an agent span are separately indexed up to 4,096 per span. Agent span events —
the evaluation, guardrail and context records carried on a model-call span — each become an
individually addressable agent event you can filter, count and alert on. Past 4,096 on one span,
the remaining events are still stored on the span and still readable there, but they are not
separately indexed. Nothing is rejected and nothing is dropped from the span. The OpenTelemetry SDK
default caps span events at 128, so reaching this needs a deliberately raised
OTEL_SPAN_EVENT_COUNT_LIMIT; if you are, split the work across spans rather than raising it
further, because one span carrying thousands of events is also slower to read.
Instrumentation attributes, service name, and exception types
Every instrumentation attribute map gets the same display-safety handling: resource, span, span-event, span-link, log-record, gauge, sum, histogram and summary data-point attributes, plus exemplar filtered attributes.
For item attributes, the count and byte limits in the table above are validation limits. Exceeding one rejects the export as described above. Attributes that pass those limits then receive a second, per-attribute character check. That check never rejects the export: a key or value containing undisplayable characters is replaced by a stable fingerprint.
Resource and span-event attributes are not subject to the per-attribute count and value limits in the table above. A span event's attribute bytes do count toward its span's total-attribute-bytes limit, because they are stored on that span. Their stored representation is bounded instead:
| Field | Stored limit |
|---|---|
Resource service.name, deployment.environment.name, deployment.environment (and environment, env, service.environment) |
255 characters |
| Any other resource or span-event attribute value | 32,768 characters |
| Resource or span-event attribute key | 512 characters |
| Resource attributes per resource | 256 |
| Span event name, exception type | 255 characters |
An undisplayable value is replaced by sha256:<digest>. A clean value that exceeds a stored
character limit keeps a short readable prefix followed by …sha256:<digest>. The fingerprint is
stable, so all telemetry from that source still groups together, and it is computed over exactly the
bytes you sent, so you can identify which value it was:
printf '%s' "<the value you sent>" | shasum -a 256Every attribute key is an identifier and may not contain newlines, carriage returns or tabs. Attribute values are prose and may contain all three — a multi-line exception stack trace, SQL statement, HTTP user agent or request body is stored intact. The resource identity values in the first row above are the exception: they are single-line identifiers because they appear as labels throughout the product.
If a resource carries more than 256 attributes, the excess is dropped in a stable order and the
number dropped is recorded on the resource as anectico.resource.attributes_dropped. service.name
and the environment attributes are never dropped.
The character-safety handling in this section is applied per attribute and never causes an export to be rejected. The item count and byte validation limits still apply before it.
Product analytics measurement limits
Trend, funnel and retention measurements run asynchronously and are bounded separately from the usage meters above:
| Limit | Value |
|---|---|
| Measurements pending or running per project | 4 |
Maximum wait for a synchronous answer (wait_millis) |
25 seconds |
| Maximum time one measurement may run | 120 seconds |
| How long a completed result stays readable | 1 hour |
| Contributors per selection | 1,000,000, read 1–100 per page |
A measurement that exceeds its running time, memory or scan budget fails outright with a named
reason rather than returning a smaller answer. A measurement is also refused outright, before it
starts, when there is not enough room to store the result it would produce — the reason says so, the
answer is never a partial one, and a measurement refused this way is not counted against your
concurrent measurements. See
measure product events for the full
definition, retry semantics, and how to poll past the wait_millis ceiling.
A funnel correlation adds
its own bounds: at most 5 event properties, 50 excluded events, 50 returned signals, a minimum
support of at most 10,000, and 1,000 ranked candidates. A definition above one is refused with
QUERY_CORRELATION_LIMIT; anectico analytics capabilities reports the current values.
Web analytics adds its own bounds: a dimension returns at most 100
values (20 when you do not say), and the rest are combined in one other row; a day, week or month
series holds at most 100 periods. A definition above either is refused with QUERY_WEB_LIMIT. One
dimension value is at most 256 bytes (a longer one counts as missing), a service name at most 128
bytes, and one page leave reports at most seven days (604,800,000 ms) of visible time; a leave
outside that range is invalid and contributes no time. anectico analytics capabilities reports the
current values.
Heatmaps add their own bounds: a click grid is at most 50 columns by 200
rows (20 by 40 when you do not say) and a clicks result returns at most 2,000 cells, the most clicked
first, with the rest combined in one other entry; an elements result returns at most 100 elements
(20 when you do not say) plus the missing-selector row, with the rest in other. A grid or a limit
above these is refused with QUERY_HEATMAP_LIMIT. A page is at most 256 bytes, a service name 128
bytes, one selector 512 bytes (a longer one counts as no selector) and one tag name 64 bytes. A
measurement whose selections would list more than 20,000,000 participant rows in all fails with
PRODUCT_RESULT_FAILURE_REASON_EXECUTION_BUDGET instead of publishing part of a result.
anectico analytics capabilities reports the current values.
Revenue adds its own bounds: a result holds at most 10 currencies (the
rest are counted in other_currencies, never added), a breakdown returns at most 50 values per
currency (10 when you do not say) with the rest combined in one other row, top_payers is at most
25 and a series holds at most 100 periods. A definition above a breakdown, top-payer or period
bound is refused with QUERY_REVENUE_LIMIT. An amount has four decimal places and a size of at
most 99,999,999,999.9999; an occurrence outside that is counted as invalid and measured nowhere. A
result that would list more than 20,000,000 people across all its payer selections fails with
PRODUCT_RESULT_FAILURE_REASON_EXECUTION_BUDGET. anectico analytics capabilities reports the current
values.
Surveys have their own bounds, reported by anectico surveys limits: a
project holds at most 200 surveys of every state and runs at most 20 active ones; a survey has up to
10 questions, a choice question 2 to 12 options and a route list up to 20 routes of at most 512
characters; a name is at most 200 characters, a description 2,000, a prompt 500 and an option or end
label 200; an open-text answer is at most 2,000 characters and a rating scale ends at 10 at most; a
cooldown after any survey is at most 365 days; and one visitor is offered at most three surveys at a
time. A launch, a stop or a reached response cap changes what is offered within about 15 seconds. A
definition above a bound is refused with SURVEY_LIMIT. A survey result lists at most 10 questions of
12 options each, pages open-text answers 1 to 50 at a time, and fails with
PRODUCT_RESULT_FAILURE_REASON_EXECUTION_BUDGET rather than list more than 20,000,000 people across all
its selections. anectico analytics capabilities reports the current values.
Service health snapshot
The service snapshot is a top list ordered over every service that reported activity in the window:
| Limit | Value |
|---|---|
Services returned (limit, --limit) |
1 to 200; 50 when you do not say |
| Services one window may hold | 10,000 |
Service name text to match (service_match, --match) |
256 bytes, no control characters |
Health states to select (health_filter, --health) |
One per call |
| Time one read may run | 10 seconds |
There is no next page. Choosing a health state or part of a name does not widen or shrink what is read: the same limits apply to every service that reported activity, and the selection is made over all of them before the list is cut. A window with more than 10,000 services, or a read that exceeds its time, scan or memory limit, is refused with no list rather than a partial ranking, and never as "no service matched"; narrow the window, the project or the environment. A window whose end is not after its start is refused. These values are starting engineering limits, not measured capacity, and may change once real workloads are measured.
Busy expensive reads
A few reads are expensive enough that each server runs only a few of them at once, whoever asks:
| Read | At once, per server |
|---|---|
| Service snapshot, and a trace search by exact span attribute | 8, at most 2 for one organization |
| Session replay steps, snapshot stream and report screenshots | 2, at most 1 for one organization |
A request that waits about two seconds without a free place answers 429 with Retry-After: 1 and
details.reason: "READ_ADMISSION_BUSY" (error code read_admission_busy). Nothing was read: retry
the identical request after the header,
backing off if it is refused again, and never treat it as an empty answer. A 429 without that
reason is the request rate or a limit of the request itself. A program that
shows these reads to many people should read once in its own backend and share the answer: the
service snapshot no more than once a minute per project, with an explicit project and a window of 24
hours or less, and a replay only when someone opens it. The
status board example and Polling, retries and refusals
show how.
Replay reads share the organization limit across all projects and credentials. An admitted read
normally has twenty seconds of work; an earlier request deadline applies first. Cancelling it stops
reconstruction and derivation and discards unfinished output. A recording read is bounded to 32 MiB
of decoded events, 100,000 events and 1,000 chunks, with 8 MiB per chunk. Steps have a separate
4 MiB derived-data budget and at most 200 steps per page. Oversized derived or encoded output is
refused, never returned as a successful partial reading. A 429 for that resource limit lacks
READ_ADMISSION_BUSY; waiting for capacity does not fix an oversized request. Missing chunks, limited related signals and
incomplete coverage stay explicit. These bounds do not qualify browser capture or privacy.
Read-only SQL over events
Read-only SQL runs one SELECT over a single table, events, and has its own
bounds. GET /api/v1/analytics/sql/capabilities reports the current values.
| Limit | Value |
|---|---|
| Window | Required; at most 92 days |
| Events loaded into a run | 1,000,000 events and 256 MiB. A window that holds more fails with SQL_ERROR_CODE_SLICE_TOO_LARGE; the input is never silently cut |
| Rows returned | 1,000 when you do not say; at most 10,000 (MCP: 100, at most 1,000) |
| Size of the returned rows | 8 MiB. A longer result is cut and truncated is true |
| Columns in a result | 200 |
| Statement size | 16,384 bytes |
| Execution time | 30 seconds |
| Memory per statement | 512 MiB |
| Rows a statement may read | 20,000,000 |
| Concurrent runs | 1 per organization |
| Rate | 20 runs a minute and 300 an hour per organization, counting statements that are refused; beyond it, REST answers 429 |
Scheduled reports
A scheduled report is bounded separately from the usage
meters above. These are enforced limits, not plan tiers: they are the same on every plan, and
GET /api/v1/reports/limits returns them.
| Limit | Value |
|---|---|
| Scheduled reports per project | 50 |
| Recipients per report | 20 |
| Name / note length | 120 / 1,000 characters |
| Rendered sections in a dashboard report | 12 (other widgets are listed with a link) |
| Table rows / columns per section | 10 / 6 |
| Shortest interval between scheduled runs | 1 day |
| Fixed day of the month | 1 to 28; the last day of the month covers the rest |
| Oldest scheduled time that is still sent | 6 hours; an older one is skipped and recorded |
| Runs waiting at once per report | 3 |
| Run history | 180 days |
After downtime only the latest due run is sent. Channel types that carry a report are email, Slack and webhook.
Warehouse export
Warehouse export is bounded separately from the usage meters above.
These are enforced limits, not plan tiers: they are the same on every plan, and
GET /api/v1/warehouse/limits returns them.
| Limit | Value |
|---|---|
| Destinations per project | 10 |
| Exports per project | 20 |
| Event names in an export's filter | 50 |
| Name length | 120 characters |
| Backfill lookback | 30 days |
| Rows per run | 3,000,000 |
| Bytes per run | 4 GiB (one event may be at most 3 MiB) |
| Rows / bytes per part | 500,000 / 256 MiB |
| Shortest interval between runs | 1 hour |
| Safety lag before an events window runs | 10 minutes |
| Windows caught up per pass after downtime | 24 |
| Oldest audience snapshot time still written | 12 hours |
| Attempts against a destination that does not answer | 8 |
| Manual runs waiting at once per export | 3 |
| Run history | 180 days |
| Destination connection tests | 30 an hour and 200 a day per organization; beyond it, REST answers 429 |
Destination types are limited to S3-compatible storage, and an audience export is limited to ordinary cohorts.
Person data archives
There is no whole-run identifier count limit. Each archive is bounded by its configured uncompressed size (default 2 GiB), one record is at most 64 MiB, and a build attempt has at most two hours. Exceeding an enforced limit fails the export without a partial archive. Temporary selection identifiers are deleted after the build, and abandoned selections expire. See Export a person's data.
Anectico Live
A live screen is bounded separately from the usage meters above. These are enforced limits, not plan tiers: they are the same on every plan.
| Limit | Value |
|---|---|
| Panels per screen | 12 |
| Trend panels per screen | 4 |
| Panel title | 120 characters |
| Note text | 500 characters |
| Fastest refresh, trend panel | 60 seconds |
| Fastest refresh, count panels | 30 seconds |
| Viewing-link lifetime | 30 days by default; no scheduled expiry is an explicit choice |
| Display session, idle | 24 hours, extended by use |
| Display session, absolute | 30 days, never extended |
| Reads of one viewing link | 120 per minute |
Trend panels are capped at four because a project may run four product-analytics measurements at once, and a live screen must leave room for the measurements you run by hand. A trend panel refused for capacity is shown as Delayed and retried on the next cycle as the identical request; it is never queued and never escalated.
Refresh happens on a server timer rather than on a viewer's poll, so the cost of a screen does not grow with the number of people watching it, and a screen nobody has opened recently is not refreshed at all. Reading a link far above a display's own cadence is throttled, as is exchanging a link's secret for a session.
More screens is the way past the panel budget: publish two screens with two links rather than one crowded screen. See Live screen templates and panels.
When a limit is reached
Anectico warns before a limit is exhausted. Under the planned policy, verbose logs degrade before spans,
while errors continue to ingest and alerts continue to evaluate. New replay sessions can be paused.
Clients should honor 429 responses and Retry-After; they should not retry in a tight loop.
The OTLP gRPC endpoint carries no HTTP status, so a throttled export is answered with
RESOURCE_EXHAUSTED accompanied by a retry delay. Standard OpenTelemetry exporters read that delay
and retry the batch automatically; no client change is needed. The delay matches the Retry-After
value the HTTP endpoint returns for the same condition.
Use Billing and usage in the Console (/billing), or anectico usage, to view current plan and usage.
- Review usage, model prices and decision scoring
- Keep metric series low-cardinality
- REST API errors and retries
- Measure product events
Deleting a project or organization
Deleting a project revokes its API credentials and display links and starts removing its saved intake sources, derived log-metric configuration, privacy settings and status-page drafts, incidents, maintenance, publication copies, subscribers and pending notification material. Display sessions are removed. Public-page withdrawal and custom-domain release must finish before the page's remaining stored content is removed; temporary service failures can delay this work. A retired public page address remains reserved to prevent reuse.
Deleting an organization applies that removal to every project and also removes its usage counters, cached payment account details, purchase links, change previews and sign-in refresh sessions. Deleting a single project preserves organization-wide usage and payment state. Payment cleanup also runs when checkout is disabled.
Security and financial audit records, revoked credential history and minimal records needed to prevent deleted data or authority returning are retained. These records do not restore access to a deleted project or organization.
Technical asset declarations
A project can hold 1,000 distinct technical asset declarations across environments and
kinds. Replaying an original result or replacing the same declaration does not consume
another slot; a new declaration or shadow adoption at capacity refuses with
asset_declaration_limit. Preview and declaration never create a sighting. See
Declare an asset before it runs
for selector, version and hash and byte bounds.
Preparing a replacement or adoption requires no more than 1,000 versions, 1,000 observation identities and 1,000 shadow-review signals on the selected asset. Larger records refuse as ineligible; a partial preview cannot be confirmed.
Browser aggregate sharing
A project has at most 100 active grants. Each names at most 10 exact results, 3 closed selectors and 5 exact origins; creation is bounded to 16 KiB. Grant expiry is between five minutes and 90 days, bounded by parent expiry. Runtime tokens last at most five minutes without refresh; projections refuse above 1 MiB. Parent transport and operation accounting applies, and unchecked allowance is unknown.
See Share a saved aggregate with a browser page for the full credential, theft, lifetime, privacy and external-copy contract.
Recent-customer top lists
Recent customers measures observed errors, person-linked traces and product events in one project. Default: last 24 hours and top 25; explicit windows span at most seven days and limits are 1–100. Product and technical history floors apply separately. The current identity admission ceiling is 512 distinct source keys. Exceeding a scan or identity limit refuses the whole ranking, without a partial list or invented totals. One accepted read uses one query operation budget; it creates no audience or additional event meter. The result never establishes upstream completeness or recovery of expired history.
Static aggregate publication
A publishable grant names one saved result, one to three closed projections and one to five exact origins. Required expiry is five minutes to 30 days, within parent expiry. Each grant shares the existing 100-active-grants project ceiling, 16 KiB creation body and 1 MiB output ceiling. Reads spend the same two-per-second, burst-20 grant allowance and the parent's and workspace's request allowances. Counter outages say unchecked and unknown, never measured zero or known remaining capacity; current authorization outages refuse. Saved-result polling creates no measurement execution.
Observed reliability reads and previews
Observed customer reliability reads are available on every tier within installed technical history, current source permissions and the existing execution-query budget. They introduce no separate usage bill or declared reliability-specific paid allowance. Account owner and content policy checks still apply. A refused optional read is unavailable, never healthy.
A reliability preview describes a proposed person or account read. It is advisory and reserves nothing: no scan, execution query, scheduler slot or later authorization. Actual measurement uses the existing query operation budget. Preview metadata reads still follow the normal request allowance and activity recording. There is no separate usage price for observed reliability.
The normalized request fixes the service, exact selectors, definition, exclusions and absolute
requested interval. Compare it with the disclosed effective interval and installed history
floor. complete, partially_covered and outside_retention describe retained history. Partial
reads measure only the effective interval; measurement_state=outside_history means no measurement
because the requested interval is outside retention, not zero observed requests. Unknown history, unavailable execution and missing
current authority are separate checks. A preview is no promise that a later read will run.
A small output page does not estimate the underlying work. Source rows, bytes, subject cardinality and used work remain unknown. Read the actual effective work limits when available; unavailable limits remain unavailable. The interactive window defaults to 24 hours and spans at most seven days. Rankings default to 25 results and cap at 100, with at most 2000 subject groups. Detail output caps at ten operations and five request references; explicit zero disables each optional output. p95 ranking requires at least 100 valid durations and p99 at least 1000, or a higher caller-supplied minimum. Exact details may show fewer samples with an insufficiency warning.
Four measurements accept at most 200 distinct --exclude-http-status integers from 400 through
599; the default set is empty. Exclusions remove attempts from both outcomes and latency, and
must match between preview, execution and comparison. Account types and keys preserve exact
UTF-8 bytes, up to 200 and 1024 bytes respectively, without NUL. Whole-window aggregation happens
before sample qualification and paging; changing page size does not lower source work.
Effective work caps can tighten with the installed workload. Current operation ceilings are
10 million source rows, 256 MiB source bytes, 128 MiB memory, three source statements and ten
seconds overall. Person row and byte caps apply per statement; account row and byte caps cover
the composition, with each possible statement receiving at most one third. Read the preview's
actual limits and work_caps.limit_basis for the installed selection. Overflow refuses the
whole measurement. No partial source prefix is presented as a complete population.
Ranks are live, with whole eligible and excluded counts separate from page count. Continue with the original absolute window; late arrivals, erasure and identity changes can alter later pages. Operation and evidence legs have separate read boundaries and omitted counts. A disabled or unavailable leg has unknown omissions. See observed reliability and shared evidence limits.
Preview does not measure percentiles, traffic completeness, historical sampling, capture settlement, future capacity or delivery effects. Checked refusals and possible future refusals remain distinct. Optional profile withholding does not deny the base person measurement.
Account objective safety limits
Every tier permits at most 20 active exact account objectives per project, with cadence at least five minutes. Paused creation and metadata preview reserve no active slot. Source execution uses the existing organization admission (at most two heavy reads per organization and eight per serving instance), query budget and the stricter installed work limits. The objective count ceiling is one statement, ten million source rows, 512 MiB source bytes, 128 MiB memory and ten seconds of source execution within at most 30 seconds overall, shortened by a rule timeout or caller deadline. Results disclose effective limits; a small returned account does not establish a cheap scan. Overflow and timeout withhold decisions. These safety limits set no price or plan allowance. Strict activation additionally needs every required interval retained, settled and unsampled under accepted-intake history; unknown coverage is not evaluated, never healthy.
Account-value work
The following are provisional engineering ceilings, pending capacity qualification; they are not measured throughput, a service guarantee, included plan allowances or prices. The connection and automated-work catalog adds no separate account-value allowance or query charge. No customer-value dollar meter, financial ingestion charge or conversion is introduced. Existing request, query, export and agent-operation budgets still apply.
| Exact job | Provisional bound |
|---|---|
| Declaration import | 500 unique rows and 1 MiB input; validate the complete file; no automatic splitting. |
| Server confirmation preview | 4 MiB complete before and proposed content; ten-minute confirmation token. |
| Declaration list and export | Default 20, maximum 100 rows; 1 MiB complete encoded page; current-page observations. |
| Requested financial window | 90 days, absolute half-open timestamps; actual source retention can shorten it. |
| Identity context | 150,000 exact aliases and 32 MiB combined input and returned context. |
| Account context | 50,000 exact account keys and 32 MiB business context. |
| Selected error occurrences | 3,000,000, before any display cut. |
| Observed model calls | 1,000,000, with at most 50,000 distinct trace contexts. |
| Financial source work | 20 million cumulative source and context rows, including refresh, validation and one reassembly. |
| Displayed account or ranked-issue rows | Default 20, maximum 100; full source totals or ranking precede this cap. |
| Explicit or canonical issue union | At most 100 canonical issues. |
| Incident case links | At most 1,000 raw links and 1 MiB checked-link metadata, independently of the canonical-issue cap. Unsupported and duplicate raw links still consume work. |
| Account–issue matrix | 100,000 distinct pairs, independently of the alias and account caps. One account across many issues still consumes pairs. |
| Accounted aggregation buffers | 128 MiB, independent of matrix count; a large entry can refuse sooner. |
| Each source statement | At most 10 seconds, 10 million scanned rows, 512 MiB read bytes and 128 MiB memory; limits throw rather than truncate. |
| End-to-end financial read | Original 30-second deadline, including retry and context work and waiting; an earlier caller deadline wins. |
| Financial admission | Two active jobs per organization within an owning read instance, four total in that instance, at most two seconds waiting. These are instance bounds, not a distributed organization-wide limit. |
Each owner can refuse sooner under its applicable source, memory, query or plan budget. Source refusals identify the crossed limit in rows, read bytes, seconds or temporary bytes when it is known; an unidentified source limit does not claim a row overflow. Raw incident links, canonical issues, matrix pairs and bytes are independent dimensions, never substitutes for one another. Overflow, cancellation, failed source or repeated state drift returns no successful partial financial result. Do not split a refused exact union or import silently. A display limit cannot reduce the source work required for exact totals. See declared account value for coverage and interpretation.
Support story limits
support story defaults to 24 hours, maximum seven days; the end is exclusive and cannot be in the future. Threshold defaults to 3000 ms, each page to 20 rows, explicit limits 1–50. Complete aliases are bounded at 512; technical source scans at ten million rows and three seconds each, with at most two concurrent sources. A bound is disclosed, never converted to empty evidence. Continue one section using its issued cursor and unchanged absolute bounds, threshold and selection. These engineering bounds are not throughput or pricing promises. See Support story.
Recorded support complaint classification
The no-matching-report read checks at most 10,000 recorded contact facts, in twenty pages of 500, under a single three-second source budget. Exactly 10,000 requires complete exhaustion; a continuation excludes the whole source. Current identity verification has a separate bound of 250,000 distinct keys and 32 MiB. Exceeding either bound never produces sampled absence. Support facts expire 30 days after contact time. Backfilled recording does not extend that lifetime. These are read controls, not complete external support coverage or throughput promises.
Survey session correlation and identity coverage
Shown, response and dismissal calls accept an optional source session_id: at most 200 UTF-8
bytes, with unsafe identifier and control characters refused. Missing or empty means not collected.
The first accepted operation keeps its original person, session and timestamp across retries;
a later session cannot move it. Session correlation does not establish a recording or query visibility.
Delivery requires complete coverage of at most 100 unique linked visitor IDs. Above it,
SURVEY_IDENTITY_COVERAGE_UNSUPPORTED refuses before a partial offer or outcome is written.
A temporary identity outage is a retryable failure, separate from a valid empty offer. Person export
and erasure retain their full identity selection. Multiple selected choices produce multiple
pooled event rows; one accepted response is still one response.
Recorded contact bounds
A contact expires 30 days from its actual reported time, not recording or retry time. Future and already expired times refuse. Capacity is 1,000 new facts per project per rolling recording day and 30,000 retained rows, including minimal withdrawn outcomes. Preview creates no fact, admission or accepted write. Aliases are at most 256 bytes; passive account, ticket and contact coordinates are nonblank single-line UTF-8 at most 255 bytes each. Complete story identity is bounded to 512 aliases. These engineering controls promise neither throughput nor complete external support coverage.