Tripline

Errors and performance · Sentry-compatible

Every error, yours.

Tripline speaks the Sentry ingest protocol, so every app instruments with the stock Sentry SDKs and sentry-cli. Tripline is only ever the server: one Go binary, events in your Postgres, the console behind Latchkey.

post an envelope the way an SDK would
$ printf '{}\n{"type":"event"}\n{"message":"hello"}\n' \  | curl -s -X POST "https://ingest.tripline.id/api/<project>/envelope/" \      -H "X-Sentry-Auth: Sentry sentry_version=7, sentry_key=<public key>" \      --data-binary @-{"id":"9c1f0e2a7b8d4e3f"}

What it does

The parts of Sentry you actually use.

Ingest, grouping, alerts and performance, on one binary and one database. Nothing to license, nothing that leaves your infrastructure.

Stock SDKs, real protocol

Envelopes and the legacy store endpoint, DSN auth from the header or the envelope, gzip and deflate. Point sentry-cli and any Sentry SDK at it and change nothing else.

Issues, regressions, spikes

Every event is grouped into an issue by fingerprint, exception and in-app frames, or message. Resolving pins the release; an event from a later release reopens it. Hourly counts flag spikes.

Alert rules

Per project: new issue, regression, spike above a threshold in a window. Delivered by email or a signed webhook (X-Tripline-Signature), with a per-issue cooldown so nothing fires twice.

Performance

Transactions with a waterfall, p50 and p95 from bucket percentiles, and mobile vitals. Fourteen days of series, day-partitioned, kept outside the event log.

DSN keys are Latchkey keys

The public key in a DSN is a Latchkey publishable key minted on your tenant. Mint, revoke, expiry and last-used live in the Latchkey console; ingest resolves locally and verifies with a ten-minute cache.

Tenants and signup

A tripline tenant is a Latchkey tenant. Sign in with your Latchkey identity, name your organisation, get admin, invite the team. Staff of the tripline org see every tenant.

How it goes

Three steps to the first issue.

  1. 01

    Create a project

    In the console, under your tenant: a slug and a platform. Tripline mints the DSN and shows it once.

  2. 02

    Install the SDK with the DSN

    The stock Sentry SDK for your language, dsn: "https://<key>@ingest.tripline.id/<project>". Releases and environments come through as they always did.

  3. 03

    See the first issue

    It appears grouped, with its release and environment, under the project. Add an alert rule so the next one emails you.

In the console

Scan, then drill.

Issues

One row per fingerprint.

First and last seen, the release it started in, the count this hour, and whether it regressed. ⌘K searches issues; G then P switches project.
app.tripline.id/o/example/p/backend

backend

Issues

Performance

Alerts

Settings

IssueLast seenRelease1h
pgx: context deadline exceeded2m ago1.14.217 ↑
TypeError: cannot read 'id' of undefined41m ago1.14.23
regressed · missing tenant header3h ago1.14.01

Performance

p95 by transaction.

Transactions listed by p50 and p95 over the window, the slow ones with a waterfall of their spans. Mobile vitals beside them.

Alerts

Rules and what they sent.

Every rule with its channel and cooldown; every notification with its delivery attempts, dead letters included.

Questions

Asked already.

Do I need to change my app?
No. Keep the Sentry SDK you have and change the DSN. Tripline accepts envelopes exactly as Sentry does and tells SDKs, through rate-limit headers, which item types it does not take yet.
What is not there yet?
Sessions, client reports, check-ins, profiles, replays and attachments are accepted and dropped or refused until their phases. Errors and performance are the product today.
Where does the data live?
Postgres, on your infrastructure. Error events are kept for 90 days, transactions and vitals for 14, partitioned by day and dropped by a daily maintenance job.

Point the SDK here.

Create a project, paste the DSN, watch the first issue arrive.