beta · onboarding teams now

Error tracking and product analytics. One flat bill.

Both jobs, in every tier, each with its own budget, so a week of noisy errors cannot eat the analytics you are paying for. The price on the tier is the bill.

What that buys you is easiest to show rather than claim, so the rest of this page is one Tuesday night on a real stack: the exception, the alert, the late source maps, and the checkout funnel it dented by morning.

already_on_sentry? Point the DSN at us. Errors flow tonight.

in.vinktar.com · v1/batch · api/1/envelope● receiving
events/s 1,284errors/min 3
trackPricing Viewedanon_2f3a
identifyalex@acme.comanon_2f3a → u_8aa1
trackCheckout Startedu_8aa1
errorTypeErrort.price is undefined
trackCheckout Failedu_8aa1

what_you_get

Two products. One bill. Neither eats the other.

Errors, from the first occurrence

Grouped from the frames you shipped, before any source map exists. Alerting on every tier, including the free one.

Analytics on the same stream

Dashboards, funnels, retention and a SQL editor over your raw events. Nothing is sampled, at any tier.

Two budgets, one number

Events and errors each get their own monthly budget, so a week on fire cannot spend the analytics you are paying for.

shortest_way_in

Keep your Sentry SDK. Change one line.

Any Sentry SDK works against our envelope route unchanged, in any language they support. Errors flow tonight; transactions and replays are discarded, and we say so rather than letting you find out.

dsn: 'https://…@ingest.sentry.io/451'

dsn: 'https://vnk_pk_…@in.vinktar.com/1'

# send setUser to join errors to your events

the_incident

Nineteen minutes, from deploy to closed.

One Tuesday night, minute by minute. Nothing here is a roadmap: every line is a route, a rule or a rollup that runs today.

22:41

deploy

You ship. The release names itself.

A release is a string you already send. web@1.4.2 registers on the first event that carries it, and every error after it is stamped with the same string, so “since when” is never a guess.

22:43

crash

The first exception, grouped before your maps exist.

The fingerprint is built from the frames you shipped, not from the frames a source map would reveal later. Occurrence one and occurrence four hundred are one issue from the start, so the alert that fires a second later names something that already has a history.

issues · production · last 15m

TypeError cart.total is not a function

checkout.tsx:214 · web@1.4.2 · first seen 22:43:12

312

22:44

alert

One rule fires. One project's budget moves.

The alert goes out by email, webhook or Slack. The spike is valved on this project's own rate budget, so the other projects in the workspace keep flowing at full speed while this one is on fire.

events2,048,113 of 5,000,000
errors · including tuesday61,904 of 1,000,000

separate columns · neither borrows from the other

22:47

maps

The maps land four minutes late. History heals.

CI finishing after the crash is the normal case, not the exception. When the upload lands, occurrences that arrived without symbols are re-symbolicated back through the last seven days, up to five thousand of them, and the issue reads as though the maps had been there at 22:43.

22:43 · as received

at t (main.9f2c.js:1:48213)

at r (main.9f2c.js:1:12904)

at n (vendor.4b1a.js:1:88301)

22:47 · after the maps

at total (src/cart/checkout.tsx:214:9)

at renderSummary (src/cart/Summary.tsx:41:5)

at commitRoot (react-dom)

23:02

fixed

You ship the fix and the graph goes quiet.

web@1.4.3 registers, occurrences stop arriving, and the issue is resolved against a release you can name. That is the errors half done. The interesting part is what the other half was recording the whole time.

09:00

+1 day

The morning question: what did it cost?

The events were already there. Same warehouse, same query surface, no export and no second vendor: the checkout funnel for that window, with the three people who hit the exception sitting in it as three rows you can open.

funnel · signup → subscribe

Visited100% · 48.2k
Signed up34% · 16.4k
Activated19% · 9.1k
Subscribed7% · 3.4k

one_identity

An error is an event.

Both halves write the same device-to-user graph, and every read on both sides resolves through it. Anonymous browsing and signed-in activity land on one customer, which is why the funnel above and the issue above can be about the same three people.

  • trackCheckout Started
  • errorTypeError
  • trackCheckout Failed
u_8aa1

> did the drop and the exception

> happen to the same person?

# one warehouse, one identity, so the question is answerable

It needs one thing from you: the same user id on both streams. A Sentry DSN pointed here without setUser arrives anonymous, and anonymous errors join to nothing. Send an id and the spine closes.

and_the_other_half

The events were already there.

One warehouse, so the product questions are answered by the same stream that caught the crash. Nothing is sampled, at any tier.

vinktar.com · dashboards● live

weekly_active

184.2k +12.4%

conversion

7.1% +0.4pp

trend · weekly_active

Trends, percentiles and formulas over your live stream. We never sample your data.

get_data_in

Three ways in. Five doors.

No package to wait for: the SDKs are in testing, and what works today is the HTTP contract, plus any Sentry SDK pointed at a Vinktar DSN.

curl in.vinktar.com/v1/batch \ -H 'X-Vinktar-Key: vnk_pk_…' \ -d '{"batch":[{"name":"signup"}]}'

methodpathlands in
POST/v1/batchevents
POST/v1/identifyidentities
GET/v1/pixel.gifevents
POST/v1/errorserror_events
POST/api/{id}/envelope/error_events
one identity

The whole contract is published, not summarised.

Every route, every field, every cap, the four rate-limit codes and what each one means for a retry loop, plus a section on what an SDK author will look for and not find. It is the document our own SDKs are written against, and it is a published contract: renaming anything in it breaks somebody.

the_bill

A bill that cannot surprise you.

A night like that is a spike, and a spike is where metered pricing takes its money. Caps here are fair-use soft caps, not meters: there is exactly one ladder, and it ends in a throttle rather than an invoice.

  1. 80% · 100% · 110%

    An email to the workspace owner. Nothing throttles, nothing drops.

  2. 2× the cap

    Ingest pauses with a 429 and a Retry-After. Dashboards, alerts and history keep working.

  3. never

    An overage invoice. The price on the tier is the bill, whatever the month does.

Dimensionfree$0starter$99team$299business$999
events / mo1M5M20M50M
errors / mo100k1M10M50M
history30 days90 days1 year2 years
ingest rate50/s sustained · 200/s burst200/s sustained · 1k/s burst500/s sustained · 2k/s burst2k/s sustained · 5k/s burst
alert rules2 alert rules per project10 alert rules per projectUnlimited alert rulesUnlimited alert rules
source maps50 MB source maps500 MB source maps2 GB source maps10 GB source maps
seats · projectsUnlimitedUnlimitedUnlimitedUnlimited

Billed monthly, cancel any time. Business: set up by hand, not through checkout. Past 50M events a month, or need custom volume, retention or rate caps? Talk to us

Not sure which tier a real month lands in? Put your own volumes in.

when_we_are_not_the_answer

Three times you should buy elsewhere.

One flat price for two jobs is a good deal inside a band and a bad one outside it. Here is the outside, in bands rather than the one figure that happens to flatter us.

  • under ~1M events a month

    PostHog

    Their free tier is more generous than ours: the same 1M events and 100k exceptions, plus session replay and feature flags we do not have. Use it, and come back when the bill starts.

  • errors only, under ~425k a month

    Sentry

    Below that volume their metered price is under our flat one, and they have tracing, replay and profiling. We get cheaper above it, and then stop moving.

  • errors only, at any volume

    Better Stack

    Cheaper than our Starter across its whole error quota, with uptime and logs alongside. If you never wanted the analytics half, we are not the saving.

what_this_is_not

We are not becoming a platform.

  • session replay
  • feature flags
  • surveys
  • uptime monitoring
  • on-call
  • reverse-ETL

Every one of those is a real request we said no to. If you want ten products from one vendor, PostHog is genuinely better at that than we will ever be. What you get instead is both jobs done properly, on one identity, on a bill with a ceiling.

get_started

Both jobs. One bill. No overage line.

Send your first event tonight, or point a Sentry DSN and watch the errors arrive.

unlimited seats · unlimited projects · never an overage invoice