Documentation

Error tracking

Catch the exceptions your application throws, grouped into issues, on every plan including the free one. It speaks Sentry’s protocol, so you keep the SDK you already have and change one line of configuration.

Setting it up

Create a project in the dashboard and copy its DSN. Then point your existing SDK at it:

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

That is the whole integration. Any Sentry SDK works — JavaScript, Python, Ruby, Go, PHP, .NET — because it is their wire protocol rather than something like it.

The key in a DSN is not a secret. A browser SDK ships it in the page bundle, so it identifies a project and authorises nothing else. Do not build anything that assumes it is private.

How errors become issues

Events that are the same problem are grouped into one issue. Grouping uses the exception type, the message and the shape of the stack — never line numbers, because adding an import at the top of a file would otherwise split one issue into two and make a long-standing bug look new.

An issue that you resolved and that then happens again is reopened as a regression and alerts you, rather than quietly adding one more occurrence to a closed issue.

Source maps

Upload the maps for a release and a minified browser stack becomes readable. Upload them from your build with the API — see the API reference.

Maps are matched by debug_id first and by release plus filename second. They are applied when you read an issue, not when the event arrives, which has one useful consequence: a map uploaded after the errors is still applied to them. That is usually the order things happen in.

Errors attached to an incident

When monitoring opens an incident, it collects the errors your application threw while that outage was being confirmed and attaches a summary to the incident itself.

It is worth knowing why that is more useful than searching afterwards: the window stops existing once the incident does, and the events are on a retention clock that expires long before the incident does. So the summary is captured at the moment it can be, and kept with the incident afterwards.

In an agency account the summary is scoped to the workspace, so one client’s incident cannot carry another client’s stack traces into an email.

Logs from your servers and network

On Business and above a project also accepts the logs your machines already write: syslog from Linux and from Cisco and Juniper equipment, the Windows Event Log, and the macOS unified log. Point a shipper you already run at your project’s log endpoint, which is on the project page beside the DSN. There is nothing to install on the machines themselves.

Only errors are stored. Syslog severities below err, Windows levels below Error, and everything the macOS log calls Default or quieter are discarded before they are counted or charged — so a healthy host costs you nothing, and the warnings nobody would page on do not fill your issue list.

Log records group the way exceptions do, on the program that emitted them and the message rather than the host: one bad deployment across twenty web servers is one issue seen twenty times, not twenty issues. Where equipment names its own messages we group on that name, so an interface going down is one issue whichever port it was.

Because a log line repeats far more than an exception does, we keep one example of each issue per hour and count the rest. The occurrence count and the chart are exact; what you do not get is a separate copy of the hundredth identical line.

Quotas

Every plan has a monthly event allowance — 5,000 on Free, 50,000 on Starter, 250,000 on Pro, 1,000,000 on Business. Ingest is also rate limited per project, which is the case that actually happens: an exception inside a retry loop can otherwise burn a month of quota in minutes.

Individual events are kept for your plan’s error retention — seven days on Free, thirty on Starter, sixty on Pro, ninety on Business. The issues built from them outlive the events: their counts and their first and last seen stay for as long as your plan’s history retention.

What we do not do

No session replay, no performance tracing, no profiling. This is exception tracking that happens to be next to your uptime monitoring, so that “the site is up and throwing five hundred errors a minute” is one screen rather than two products.