Documentation
Errors from Sentry
Which of your customers hit an error, and when.
Kicklace isn't an error tracker and won't become one. Sentry already does that job, and it holds the one thing a CRM doesn't: the user on the event. So Kicklace takes Sentry's webhooks and answers a question neither tool answers on its own: which of my customers hit an error, and on which release.
What arrives becomes a row on the person who hit it, matched to the release it happened on. Nothing else of Sentry's payload is kept.
It's under Connections → Sentry, and only an owner or an admin can connect or disconnect it.
Setting it up
1. Make an internal integration in Sentry. Open Settings → Developer Settings → Custom
Integrations → Create New Integration → Internal Integration. Name it, paste the address Kicklace
shows you as the Webhook URL, turn on Alert Rule Action, give it Issue & Event: Read, and
under Webhooks tick issue. It installs itself on your organization when you save it.
2. Paste the Client Secret. The integration's page in Sentry shows a Client Secret. Sentry signs every post with it, and without it nothing is taken. Paste it into Kicklace; it's locked away and never shown back.
3. Point an alert at it. In Sentry a webhook is an alert action, so an alert rule is what fires it. Open Alerts → Create Alert → Issues, choose "A new issue is created", and pick the action Send a notification via your integration.
On a Business or Enterprise plan you can also tick error under the integration's Webhooks, which
sends every error rather than the first of each issue, so "how many customers hit this" is a real
figure rather than a lower bound.
What lands
One row on the person's timeline, named error:
| On the row | From |
|---|---|
| the title | Sentry's own title |
| the level | error, warning, fatal, whatever the SDK sent |
| the environment | production, staging |
| the release | the release string, exactly as your SDK set it |
| a link | web_url, which opens it in Sentry |
| the issue | so the same problem collapses onto one row |
Never stored: the stack trace, the request (its address, headers, cookies and query), the breadcrumbs, the browser and device details. None of it is a fact about a customer, and all of it is one click away in Sentry.
Who it lands on
- An email is a person. If your SDK calls
Sentry.setUser({ email }), the error lands on that person. - A user id matches somebody already here.
Sentry.setUser({ id })is your own app's user id, whichidentifywrites down. - An error about nobody lands nowhere. Kicklace won't invent a customer out of an error. Those
posts are still counted, and the page says so: "412 posts taken, none of them on anybody yet" is how
you find out your SDK never calls
setUser.
A thousand errors aren't a thousand rows
A bad deploy sends Sentry the same error four hundred times a minute. So the same person hitting the same issue inside the hour is counted onto the row already there: it reads "12 times", and the next hour starts a new row. The collapse is per person, per issue, per hour, never across people.
The release
Kicklace looks for a release whose SHA matches your release string (a SHA, or package@version with
an optional +build). Where it matches, the error carries the release, and the release's own page
says how many errors and how many people. Where it doesn't, the string is kept and nothing is joined.
Issues
Sentry also posts when an issue is created, resolved, archived or assigned. An issue is a fact about your code, not a customer, so it goes on nobody's timeline; the page keeps the last twenty by name.
When it goes wrong
A post whose signature isn't yours is refused with 401 and nothing is written. Something Kicklace
has no use for is answered 200 and ignored. Your Client Secret is in no answer.
Disconnecting stops the address answering. Every error already on a timeline stays.