Features / Platform
Integrations
Connect what you already run
Your code host, your error tracker, your issue tracker and your chat tool. The ones that are built are marked; the ones that are not say so.
- Sentryerror intake Connected
- GitHubyour repositoryConnect
- LinearissuesConnect
- SlacknotificationsConnect
- Emailinbound, through Amazon SESConnect
What it does
- GitHub, Sentry, Linear, Slack and email are live today
- Everything else in the list is visibly marked as coming
- Connections you own and can revoke at any time
- Credentials encrypted per organization, never shared
Without it
Support tools sit outside every system that holds the answer
One bug, three systems, no agreement
The customer wrote in to support. Someone pasted it into Slack. Someone else filed a shorter version in the issue tracker. It ships two weeks later and nobody tells the person who reported it.
The integrations page is a wall of logos
Half of them mean 'contact sales', a third are one-way only, and the one you came for turns out to be a webhook you have to build yourself. You learn all of this after you have signed up.
Copying the context by hand loses the useful part
The issue gets a title and one sentence. The replay, the console trail, the release and the exact stack frame stay behind in the support tool, so your engineer starts by asking for them.
How it works
Connect the five that are built
Sentry for error intake, the GitHub App for your repository, Linear for issues, Slack for notifications, and inbound email through Amazon SES. Those five are live and connectable today.
What that includes
- Sentry for error intake
- Linear for issues
- Slack for notifications
- inbound email through Amazon SES
Everything else is shown and marked
The rest of the catalog sits on the same page, grayed out and labeled coming soon. Nothing is half-wired and presented as working, and nothing is hidden to make the list look tidier than it is.
Decide what flows, and which way
Per connection: push only or two-way, how your statuses and priorities map onto theirs, whether a bug opens an issue on its own, and which parts of the captured context travel with it (the summary, the root cause, the 30-second replay, the logs, the pull request link).
What that includes
- how your statuses
- priorities map onto theirs
- the root cause
- the 30-second replay
- the logs
- the pull request link)
Credentials stay yours
Each organization's credentials are encrypted and scoped to that organization, never shared across tenants. A check in the code refuses to publish any config field whose name looks like a secret, and disconnecting revokes access.
What it means for you
The engineer opens the issue and has everything
The report, the replay, the network and console trail and a link back to the customer, in the tool they were already working in. No thread to go hunting through.
You can tell what is real before you commit
A list where coming soon says coming soon is a list you can plan against. You find the gap while you are evaluating, not in week two of using it.
The person who reported it hears back
The issue and the conversation are the same record, so closing one closes the loop on the other without anyone remembering to.
The honest limit: Five connections are live: Sentry, GitHub, Linear, Slack and inbound email. Everything else in the catalog is visible but not connectable yet, and we are not putting dates against the rest until they are built.