The Trinity Beast Infrastructure — Webhook Delivery Reporting

1. Overview — The Promise Behind the Numbers

When you subscribe to Webhook Push, you are buying a promise that is unusually specific: we will send you prices for the assets you selected, at the interval your tier guarantees, over the transport you chose, and we will keep doing it without you asking. Most of our engineering effort goes into keeping that promise. This document is about the other half of the work — proving we kept it, in numbers you can audit.

That distinction matters more than it might sound. A delivery system that reports on itself honestly is rarer than it should be. It is very easy to build a dashboard that shows a reassuring green number, because the easiest metrics to compute are the ones that flatter the system computing them. We have deliberately gone the other direction. Several of the numbers in your Delivery Reports are designed to make our own shortfalls visible, including one that will show you a market limitation we cannot engineer our way out of.

None of this is an add-on. There is no reporting tier, no per-query charge, and no entitlement flag to buy. Ownership of a webhook subscription is the only gate — if you are an Associate, this is already switched on for you.

How to read this document

Sections 2 through 4 explain the machinery — what we record, how we decide what constitutes a single push, and how ten million rows become an instant answer. Sections 5 through 8 define each metric precisely, including the reasoning behind definitions that could reasonably have gone another way. Section 9 is the practical reference: where to click, what to call, what every field means. Sections 10 through 12 cover language, freshness, and cost.

If you only read one section, read 6.3. It explains the single field that separates a number you can act on from a number you should treat as an estimate — and it is the field we are proudest of.

2. The Delivery Log — What We Record

Everything in your Delivery Reports is derived from one table in Aurora: webhook_delivery_log. Understanding its shape explains almost every design decision that follows, so it is worth one careful paragraph.

We write one row per asset, per transport, per push. Not one row per push. Not one row per asset. One row for every combination. If you are on Webhook Standard with 30 assets configured and delivery_method=both, a single delivery cycle writes 60 rows — 30 for the HTTPS leg and 30 for the UDP leg.

That granularity is a deliberate choice with a real cost. It means an Enterprise subscriber at 60 assets, a 3-second interval, and both transports generates on the order of 3.5 million rows per day. We accepted that cost because the alternative — recording one summary row per push — would make it impossible to answer the question Associates actually ask, which is never "did the push go out" but almost always "why is SOL missing from my feed?" You cannot answer a per-asset question from per-push data. So we store per-asset data, and we built the rest of the system to make that affordable.

2.1 What Each Row Holds

2.2 Retention — 33 Days

Raw delivery rows are kept for 33 days and then removed, oldest first, by a scheduled job inside Aurora that runs nightly at 2:30 AM Eastern. 33 days is 11 × 3, and multiples of 3 are a house convention throughout this infrastructure — you will notice it in our retention windows, batch sizes, memory allocations, and tier intervals. This window applies the same way to every subscriber on this delivery engine, whether you are a paid Associate or a free-tier Partner.

Two things follow from that window, and both are good news:

• Your reports are not limited to 33 days. The daily rollup described in section 4 is a permanent summary. Raw rows age out; your day-by-day history does not.
• Per-asset drill-down is limited to 33 days. Filtering a report by a specific asset reads the raw log, so that view has the shorter horizon. If you need per-asset evidence for a specific incident, export it while it is inside the window.

3. What Counts as One Push

Here is a question that sounds trivial and is not: given a pile of asset rows, which of them belong to the same push?

Every number in your report depends on the answer. Delivery rate is successful pushes over total pushes. Asset coverage is assets per push. Get the grouping wrong and every metric downstream is wrong — not slightly wrong, but wrong in ways that look plausible. We know the shape of that failure precisely, because we shipped it.

3.1 Why This Question Is Harder Than It Looks

Each push carries a sequence_number, and the obvious move is to group by it. That is what we did originally, and it is wrong for a reason worth understanding.

The sequence counter lives in memory inside the container that is delivering to you, and it resets to 1 whenever that container restarts. On the wire this is exactly right — you receive a clean, monotonically increasing sequence from your delivery loop, which is what lets you detect a gap. In a database spanning days and deployments, it is a disaster: after six deploys in one day, six completely unrelated pushes all carry sequence_number = 1.

Grouping by that number alone merged pushes that were hours apart. One observed group held 96 asset rows spanning four separate minutes. The consequences were not subtle:

• Asset coverage read 124.87% — an impossible number, since you cannot receive more assets than you configured
• Push counts came in at roughly half the real figure
• Failures were masked. A merged group counted as delivered if any row in it succeeded, so a genuine failure could be absorbed by a successful push from hours earlier

The instinctive fix is to group by time instead — rows close together are one push. That fails too, and it fails in the opposite direction. During a rolling deploy, two containers briefly deliver to you at once, each with its own counter. Grouped by time alone, those two concurrent pushes merge into one, and we measured a single "push" containing 222 assets for a subscription configured with 30.

3.2 The Rule — Two Signals, Both Required

A push is a set of rows that share a sequence number and are time-adjacent within 1500 milliseconds. Both conditions, together. Either one alone is demonstrably broken; combined, neither failure mode is possible.

That third row is the confirmation that mattered. The maximum assets in any single push came out at exactly the subscription's configured limit — not near it, exactly it. A grouping rule that produces an impossible maximum is broken; one that lands precisely on the real ceiling is measuring something true.

flowchart TB
    subgraph Rows["Raw asset rows in webhook_delivery_log"]
        R1["seq=1 · BTC · 09:00:00.000"]
        R2["seq=1 · ETH · 09:00:00.005"]
        R3["seq=1 · SOL · 09:00:00.011"]
        R4["seq=1 · BTC · 14:22:07.000"]
        R5["seq=1 · ETH · 14:22:07.006"]
    end
    Rows --> Q{"Same sequence number?"}
    Q -->|"no"| SEP["Different pushes"]
    Q -->|"yes"| T{"Gap under 1500ms
from previous row?"}
    T -->|"yes"| SAME["Same push"]
    T -->|"no"| NEW["New push — counter reset
after a container restart"]
    SAME --> P1["Push A — 3 assets
09:00:00"]
    NEW --> P2["Push B — 2 assets
14:22:07"]
    P1 --> OK["Coverage, delivery rate,
and latency computed per push"]
    P2 --> OK
    style P1 fill:#064e3b,stroke:#10b981,color:#d1fae5
    style P2 fill:#064e3b,stroke:#10b981,color:#d1fae5
    style OK fill:#1e3a5f,stroke:#60a5fa,color:#dbeafe
    style NEW fill:#7c2d12,stroke:#FF9900,color:#fed7aa
        

3.3 Two Transports Are Two Push Events

If you subscribe with delivery_method=both, one delivery cycle produces two push events in your reports — one for HTTPS, one for UDP. We do not merge them, and that is a feature rather than an accounting artifact.

The reason is that your two transports can fail completely independently, and a merged number would hide it. Here is a real subscription from our own test fleet, on a single day:

That subscription's HTTPS endpoint was deliberately pointed at a hostname that does not resolve, while its UDP endpoint was live. Reported per transport, the numbers tell you exactly what is wrong in one glance: your UDP feed is perfect, your HTTPS endpoint is unreachable, go check your URL. Merged into one figure, the same day would have read as roughly 50% delivery — a number that describes nothing real, points at no action, and would have you suspecting our infrastructure rather than your endpoint.

4. The Rollup — Ten Million Rows, Instant Answers

Your Delivery Reports are fast, and they stay fast no matter how much history accumulates. That is not because the delivery log is small — it is currently over ten million rows and more than two gigabytes. It is because your reports never read it.

Between the raw log and your report sits webhook_delivery_daily, a rollup table holding one row per subscription, per day, per transport. A month of history is about 60 rows for you. Querying it is trivially cheap, and the cost does not grow as the raw log does.

flowchart LR
    subgraph Deliver["BeastWebhook — delivery engine"]
        LOOP["Per-subscription
delivery loop"]
        CACHE["WebSocket price cache
6 exchanges"]
        LOOP --> CACHE
    end
    subgraph Wire["Your endpoints"]
        HTTPS["HTTPS
signed, 3 retries"]
        UDP["UDP
fire and forget"]
    end
    subgraph Store["Aurora PostgreSQL"]
        RAW["webhook_delivery_log
one row per asset per transport
33-day retention"]
        DAILY["webhook_delivery_daily
one row per day per transport
permanent"]
    end
    subgraph Refresh["Rollup refresh"]
        CRON["pg_cron
every 15 minutes
trailing 2 days"]
        NIGHT["BeastReconciler
nightly, trailing 3 days
all subscriptions"]
        BTN["Refresh Now
on demand, today only"]
    end
    subgraph Read["What you read"]
        DASH["Account Dashboard
Delivery Reports panel"]
        API["GET /webhook/reports/*
JSON · CSV · TSV · Text"]
    end
    LOOP --> HTTPS
    LOOP --> UDP
    HTTPS --> RAW
    UDP --> RAW
    RAW --> CRON
    RAW --> NIGHT
    RAW --> BTN
    CRON --> DAILY
    NIGHT --> DAILY
    BTN --> DAILY
    DAILY --> DASH
    DAILY --> API
    style RAW fill:#7c2d12,stroke:#FF9900,color:#fed7aa
    style DAILY fill:#064e3b,stroke:#10b981,color:#d1fae5
    style DASH fill:#1e3a5f,stroke:#60a5fa,color:#dbeafe
    style API fill:#1e3a5f,stroke:#60a5fa,color:#dbeafe
        

What the rollup computes for each day

The refresh groups your raw rows into pushes using the rule from section 3, then aggregates those pushes into one row per transport per day. Days are bucketed in America/New_York time, so a "day" in your report is an Eastern calendar day rather than a UTC one.

5. Delivery Rate — What It Actually Means

Delivery rate is the simplest metric in the report, and it is worth being precise about its scope because the precision is the useful part.

delivery_rate_pct = successful_events / push_events × 100

It is computed per day, per transport, and again across a whole range in the summary. A push counts as successful when we got the payload onto the network to your endpoint.

What this measures — and what it honestly cannot

For HTTPS, delivery rate is close to end-to-end truth. We sign the payload, POST it, and read your response. A 2xx means you accepted it. A 4xx means you rejected it and we stop immediately, because retrying a request your server has already refused is not resilience, it is noise. A 5xx or a connection failure gets retried 3 times with 1, 2, and 4 second backoff before we record a failure. So an HTTPS success genuinely means your server acknowledged the data.

For UDP, it cannot mean that, and we will not pretend otherwise. UDP is fire-and-forget by design — there is no acknowledgement in the protocol, which is exactly why it is the fastest option we offer and why latency-sensitive Associates choose it. A UDP success in your report means we wrote the datagram to the socket without error. If a router between us drops it, that packet is gone silently and no honest reporting system on our side could tell you.

Why a partial push still counts as delivered

A push that carried 8 of your 9 assets counts as delivered, not failed. That is deliberate, and the reasoning is worth following because it is the difference between two genuinely distinct signals.

A push is one payload per transport. It either reaches your endpoint or it does not — there is no mechanism by which 8 assets arrive and the 9th is lost in transit, because they travel together in the same message. So when only 8 assets appear, the 9th did not fail to be delivered; it had no fresh price at push time and was never in the payload at all.

We verified this holds in practice rather than assuming it: across 5,814 real pushes, we found zero with mixed status. A push's asset rows always agree, because the transport succeeds or fails as a whole.

This is why we report two separate metrics instead of collapsing them into one. Delivery rate answers "is the pipe working?" Asset coverage answers "is the pipe full?" A missing asset is a price-freshness and market-liquidity signal, not a delivery signal, and folding it into delivery rate would leave you unable to tell an endpoint problem from a thin order book.

6. Asset Coverage — The Honest Metric

Asset coverage answers the question that matters most: of the assets you selected and are paying for, how many actually arrive?

asset_coverage_pct = avg_assets_per_push / coverage_denominator × 100

Two numbers, one division. The numerator is straightforward. The denominator took three attempts to get right, produced two customer-visible defects along the way, and is the reason this document exists. Both halves are worth your attention.

6.1 The Numerator — Assets Actually Delivered

avg_assets_per_push is the average number of assets carried per push that day. An asset appears in a push when our delivery engine can resolve a current price for it at that moment. When it cannot, the asset is simply absent from that push.

Price resolution has two tiers: the delivering container's own WebSocket cache, fed directly by live trades from 6 exchanges, and failing that a cluster-wide cache shared across every node. A price is eligible for webhook delivery if it is under 5 minutes old.

So a missing asset means one of three things, all of them information rather than malfunction: the pair is thinly traded and had no recent trade, its exchange feed is quiet, or it is genuinely illiquid. Every asset in your picker is swappable at any time in your dashboard — if an asset shows persistently low coverage, that is the system telling you to trade it for a more liquid one.

6.2 The Denominator — And Why It Was Hard

Dividing by "how many assets you configured" sounds like reading one number off your subscription. It is not, and the trap is subtle: your report covers a period of time, but your subscription row only knows what you have configured right now.

Measure a whole day's average against this moment's configuration and you get a snapshot-versus-history mismatch. Our first two attempts both failed on it, in opposite directions:

Both early failures were correct arithmetic on a guessed number. That is the instructive part: the mathematics was never wrong, the input was an inference, and no amount of careful division fixes a denominator that was reconstructed after the fact.

The real fix: record it at the time

So we stopped inferring. Every push now records how many assets you had configured at the instant it was sent, in the configured_assets column. The denominator became a recorded fact instead of an archaeological reconstruction.

Two details make this trustworthy rather than merely present:

• It costs nothing. The count comes from the subscription record the delivery engine is already holding in memory. No extra query, no added latency to your feed. We would not have shipped it otherwise.
• The numerator and denominator come from one source. The exact same code that builds your delivered asset list produces the recorded count. They cannot disagree, because there is only one definition of "configured" in the system.

That second point is subtler than it looks. A recorded denominator derived even slightly differently from the delivered list would reintroduce the same class of defect one layer down — a denominator that never quite matches its own numerator. Sharing the definition is what closes it permanently.

Days that changed mid-flight

The recorded value is a push-weighted average, not a single figure, and that is precisely what makes it correct on the hardest day: one where you changed your configuration partway through.

Suppose you ran 30 assets for half a day and 9 for the other half, at 90% coverage throughout. Delivered averages 17.55; configured averages 19.5; the quotient is exactly 90%. Because both terms are push-weighted means, dividing one by the other yields total delivered over total configured — the correct aggregate ratio, with no special-casing. A single-value denominator would have picked 30 or 9 and reported 58.5% or 195%.

6.3 Coverage Basis — Every Number States Its Provenance

Every daily row carries a coverage_basis field naming where its denominator came from, and a coverage_denominator field carrying the exact value the percentage was divided by.

This field is the one we would point to if asked what distinguishes this reporting system. A metric that does not disclose its own provenance invites you to trust a reconstruction exactly as much as a measurement. The entire history of this number was numbers whose origin was unclear — so now the origin travels with the number, produced by the same function that produced the value, specifically so the two can never drift apart.

It also means you can audit us. If a coverage figure looks wrong, check the basis first: a recorded value that disagrees with your own logs is worth reporting to us as a bug. A max value that looks low on a day you changed tiers is the documented behavior described above, and the mode-based figure beside it is the better guide.

6.4 Why We Do Not Clamp at 100%

It would be easy to cap coverage at 100% so an impossible number can never appear again. We deliberately do not, and the reason is a principle worth stating: a wrong number that looks plausible is more dangerous than one that looks wrong.

The 124.87% reading was a gift. It was self-evidently impossible, so it got investigated within minutes and exposed a grouping defect that was also silently masking real delivery failures. Clamped to 100%, that same defect would have shown a perfectly reasonable figure and could have hidden for months.

So if you ever see coverage above 100% in your reports, please tell us. It means something is genuinely wrong, and we would very much rather hear it from you than have our own display quietly conceal it.

7. Coverage Distribution — What Averages Hide

A single average coverage figure has a structural blind spot, and it is a serious one. Consider two days that both report 87.50% coverage:

• Day A — every push delivered about 87% of its assets. Uniformly short.
• Day B — most pushes were complete, and a few collapsed to 30%.

Identical headline. Completely different problems. Day A is a market-liquidity ceiling — some of your assets are thinly traded and the average reflects it. Day B is an intermittent fault, and the two demand opposite responses: Day A means reconsider your asset selection, Day B means look at what happened at those specific moments.

An average cannot distinguish them. Not because ours is poorly implemented, but because averaging is by definition the operation that discards distribution. So we report two additional numbers alongside it, and they are designed to be read together.

Applied to the two days above, the ambiguity disappears immediately. Day A reports few or no full pushes and a minimum close to its average. Day B reports mostly full pushes and a minimum of 30%. One glance, two different stories, two different actions.

The insight this made possible

These two fields immediately taught us something about our own product that the average had been hiding. A subscription can report healthy average coverage — comfortably in the 90s — while delivering its complete configured set on only a minority of pushes. It consistently delivers nearly everything, and rarely everything.

Whether that matters depends entirely on what you are building. If you are computing a portfolio value or driving a display, near-complete every few seconds is fine. If your logic requires all N assets present in the same message before it can act, you should be watching pushes_at_full_coverage, not average coverage — and before these fields existed, there was no way for you to know the difference.

The honest framing is this: the constraint is real trading volume on real exchanges, not our engineering. As you configure more assets, the chance that every single one has a fresh price at the same instant falls, because you are necessarily reaching further down the liquidity curve. A tighter selection of well-traded assets will deliver complete pushes far more consistently than a broad selection reaching into thin markets. These fields let you measure that trade-off on your own subscription instead of taking our word for it.

7.1 Why Our Top Tier Stops at 60 Assets

This is the same measurement that set our pricing, so it is worth showing you the number it turns on. Across the 150+ assets we prewarm on 6 exchanges, here is how 24-hour trading volume actually distributes:

Only about 65 assets trade above a million dollars a day. That is the real ceiling on how many assets can carry a genuinely fresh price at a 3-second cadence, and it is why both Professional and Enterprise cap at 60 rather than something larger.

We think that decision is worth explaining rather than just presenting, because the alternative was available and we rejected it. An earlier version of the Enterprise tier advertised 150 assets. It was never deliverable in full — measured delivery sat around 70 of 150 — for the simple reason that a 150-asset selection has to reach roughly 85 assets past the liquid universe. Rather than keep a number that reads well and cannot be met, we brought the ceiling down to what the market actually supports and made the top tier differentiate on speed instead: same 60 assets, pushed twice as often.

8. Latency — What We Measure, and What We Cannot

Each day and transport reports two latency figures, both in milliseconds: avg_latency_ms and p95_latency_ms. Both are computed across delivered pushes only — a failed push's timing measures how long a failure took, which would quietly poison the number you actually care about.

Precisely what the clock covers

Two consequences follow, and both are deliberate:

• HTTPS latency includes your server. If your endpoint takes 400 ms to respond, your reported latency is roughly 400 ms. That is the honest number — it is how long the delivery genuinely took — but it means a rising HTTPS latency may be telling you about your own service rather than ours. Compare it against your UDP figure on the same day: if UDP is flat and HTTPS is climbing, the change is on your side of the wire.
• UDP latency is not receipt latency. It measures our write to the socket, which is typically sub-millisecond and always small. It cannot include network transit, because nothing acknowledges a datagram. Do not read a low UDP latency as evidence of fast arrival — read it as evidence that we are not the bottleneck.

Latency is recorded per push leg rather than per asset. Every asset row within one push carries the same value, because the payload travelled as a single message — there is no per-asset timing to record, and inventing one would be fiction.

Note that range summaries report an average but no p95. Percentiles cannot be meaningfully averaged across days — a p95 of p95s is not a p95 of anything — so rather than compute a number that would look authoritative and mean nothing, we omit it. For tail latency across a range, read the daily rows.

9. Reading Your Reports

Two ways in, backed by the same data and the same arithmetic: the Account Dashboard for looking, the API for scripting. They cannot disagree, because they resolve every number through shared logic — a deliberate choice after we learned how easily two implementations of one metric drift into two different answers.

9.1 In the Account Dashboard

Sign in at api.cpmp-site.org/dashboard and open Delivery Reports. Login is passwordless — request a magic link, click it, you are in.

There is also a separate Delivery Log panel for live activity: your 50 most recent pushes, expandable to the individual asset prices in each, with second-precision Eastern timestamps. Use Delivery Log for "what is happening right now" and Delivery Reports for "how has this performed". At Enterprise's 3-second interval, second precision in the log is not a nicety — minute-rounded timestamps would collapse about twenty distinct pushes into one apparent moment.

9.2 Over the API

Three endpoints. Authentication is your webhook API key, presented as an X-API-Key header, an Authorization: Bearer header, or an api_key query parameter. No other entitlement is required — owning the subscription is the whole gate.

Query parameters

Examples

# Last 30 days, day by day
curl -H "X-API-Key: $WEBHOOK_KEY" \
  "https://api.cpmp-site.org/webhook/reports/daily"

# A specific month, HTTPS only, as CSV
curl -H "X-API-Key: $WEBHOOK_KEY" \
  "https://api.cpmp-site.org/webhook/reports/daily?start_date=2026-07-01&end_date=2026-07-31&method=https&format=csv" \
  -o july-https.csv

# Range summary as a human-readable block
curl -H "X-API-Key: $WEBHOOK_KEY" \
  "https://api.cpmp-site.org/webhook/reports/summary?format=text"

# One asset, to investigate a gap
curl -H "X-API-Key: $WEBHOOK_KEY" \
  "https://api.cpmp-site.org/webhook/reports/daily?asset=SOL"

# Start a refresh of today's numbers — returns immediately
curl -X POST -H "X-API-Key: $WEBHOOK_KEY" \
  "https://api.cpmp-site.org/webhook/reports/refresh"
# {"status":"started","message":"Delivery report refresh started"}

# Poll for the result (repeat every second or two until status is "done")
curl -H "X-API-Key: $WEBHOOK_KEY" \
  "https://api.cpmp-site.org/webhook/reports/refresh/status"
# {"status":"done","rows_updated":3,"refreshed_at":"2026-08-21T18:04:11Z"}

Both GET endpoints return the standard 12-field Unified Messaging Envelope with your payload in data, the same shape as every other endpoint in this infrastructure. Check status_code, throw on error, read data — and never write a fallback for a missing field, because there are none. Every field is always present. See the envelope reference for the full contract.

9.3 Complete Field Reference

Daily rows

Range summary

10. Your Reports in Your Language

Everything you read about your webhook delivery is available in 12 languages, driven by a single setting in your Account Dashboard. Not machine-translated on the fly in a browser widget — deliberately translated, stored, and served.

The 12 languages are English, Spanish, Portuguese, French, German, Russian, Hindi, Urdu, Italian, Arabic, Japanese, and Chinese (Simplified).

10.1 The Boundary — Human Language and Machine Language

That last table row is the important one, and it is a principle rather than a gap.

We translate the understanding. We never translate the execution.

Your delivery payload has fixed English field names — asset, price, source, updated_at — and they will never change based on a language preference. Think about what the alternative would mean: a customer switching their dashboard to Japanese and their parser breaking in production because price silently became 価格. A language setting is a preference about reading. It must never be a breaking change to an integration.

This is the same discipline we apply to our documentation, which is why you can read a translated page in Urdu and copy-paste a code block from it that works on the first try — code blocks, commands, identifiers and diagrams are all protected from translation. Prose is for humans; identifiers are for machines. Confusing the two is how translated technical documentation becomes useless.

flowchart TB
    SET["Account Dashboard
Profile settings"]
    SET --> PL["Correspondence language
preferred_lang"]
    SET --> AL["API language
api_lang"]
    PL --> DASH["Dashboard UI
Delivery Reports panel
12 languages · RTL aware"]
    PL --> MAIL["Webhook emails
confirmation · plan change
asset auto-adjustment"]
    PL --> DOCS["Document Library
this page, 12 languages"]
    AL --> ENV["Payload language field
declares your preference"]
    PAY["Price payload
asset · price · source · updated_at"]
    PAY --> FIXED["Field names fixed in English
never change with language"]
    ENV -.->|"travels with"| PAY
    style DASH fill:#064e3b,stroke:#10b981,color:#d1fae5
    style MAIL fill:#064e3b,stroke:#10b981,color:#d1fae5
    style DOCS fill:#064e3b,stroke:#10b981,color:#d1fae5
    style FIXED fill:#1e3a5f,stroke:#60a5fa,color:#dbeafe
    style PAY fill:#334155,stroke:#64748b,color:#e2e8f0
        

10.2 One Setting, Two Choices

Your profile offers two language choices, and the distinction is worth thirty seconds of your time because they do genuinely different jobs.

Both are saved from the same panel in one action, and both take effect immediately — your dashboard re-renders in the new language on the next load, and your emails follow from the next one sent.

11. Freshness — When the Numbers Update

Your delivery log is written the instant a push happens. Your delivery reports read the rollup, which is refreshed on a schedule. So the practical question is: how stale can a report be?

Answer: about 15 minutes, worst case.

Three overlapping paths, on purpose. The 15-minute cycle keeps your numbers current without you doing anything. The nightly pass is wider and covers every subscription, so a day is recomputed with full context after it has completely finished — and because its window is deliberately wider than one day, a single missed run heals itself on the next one rather than leaving a permanent hole. Refresh Now exists for when you are actively investigating and 15 minutes feels long.

Every refresh is an idempotent recomputation from the raw log, not an incremental adjustment. Running one twice changes nothing, and a day recomputed a week later produces the same answer it did on the day. That property is what lets us have three overlapping schedules at all without them corrupting each other.

12. What This Costs You

Nothing. There is no reporting tier, no per-query fee, no storage charge, no export limit, and no add-on to buy.

We want to be direct about why, because the reasoning is not charity and it is not a loss leader.

You are paying for delivery. Proof of delivery is part of delivery. A price feed you cannot audit is a price feed you have to take on faith, and asking you to pay extra for the evidence that we did the job you already paid for would be, frankly, a strange thing to sell. Metering it would also change our incentives in a direction we do not want: the moment reporting becomes a revenue line, there is quiet pressure to make the free view less useful. We would rather every Associate be able to check our work, all the time, at no cost, and hold us to it.

It also happens to be inexpensive to provide, and the engineering is the reason. The rollup means your report reads about 60 rows rather than scanning millions. Recording the configured count costs nothing because the value was already in memory. Storage is a table that prunes itself nightly. Good architecture is what makes generosity affordable — if this had been built as a naive query against the raw log, it would have been slow, expensive, and inevitably rationed.

What we believe you will not find elsewhere at this price

We have earned the right to say a few things plainly.

• Sub-second price delivery from 6 exchanges, pushed to you, starting at 30 dollars a month. Over your choice of signed HTTPS or raw UDP, or both simultaneously.
• A reliability metric that states its own provenance. We have not found another feed that tells you whether the number you are reading is a recorded fact or a reconstruction. It is the field we are proudest of, and it exists because we got the number wrong twice and decided the fix was transparency rather than a better guess.
• Distribution, not just averages. Most providers report an availability percentage. We report the average, the worst case, and how many deliveries were complete — including when that combination is unflattering to us.
• We lowered our own top tier rather than advertise a number we could not hit. Enterprise used to promise 150 assets. The liquidity data said roughly 65 assets trade heavily enough to support it, so we cut the ceiling to 60 and re-based the tier on push speed instead. That reduced the headline spec on our most expensive plan. We would rather sell a smaller number that is true.
• Push identity defined by measurement. The 1500-millisecond rule came from measuring real intra-push spread and real inter-push gaps in production, not from picking a comfortable number.
• 12 languages, properly done, including right-to-left. Your dashboard, your emails, and every page of this documentation.
• 33 days of history, four export formats, no metering.
• Every revenue dollar funds freedom from debt bondage in Pakistan. This is not a marketing line appended to a product. It is the reason the product exists.

And if a number in your reports ever looks wrong — especially if it looks impossible — please open a support ticket and tell us. Our assistant Rhema will pick it up immediately and route it. Two of the three defects described in this document were found by someone looking at a figure and saying "that cannot be right." That instinct is genuinely valuable to us, and we would rather hear it than not.