SLAtech Vantage reads errors from Sentry, Rollbar, Bugsnag and Application Insights, plus failed GitHub Actions runs and GitLab CI pipelines, and puts all of them into one error stream per project. There they are grouped by a single signature, classified and ranked by severity, and a task can be opened from them. Every one of these integrations is read-only.
Which tools, and what each one asks for
- Sentry: server address (sentry.io or self-hosted), organization, project and an access token.
- Rollbar: the project name and a project access token with read scope, not the token the application uses to send errors.
- Bugsnag: the project identifier, as it appears in the address, and a personal auth token.
- Application Insights: the application ID and an API key. Retention there defaults to 90 days, and there is nothing to pull from further back.
- GitHub Actions and GitLab CI: a repository or project, and a token with read access.
All tokens are stored encrypted and never shown again. Errors are pulled once an hour. The project sources screen is open today to the system operator only, so the connection is made through us.
One grouping for every source
Every error tracker has its own idea of an "error group", and they differ from one another. SLAtech Vantage uses none of them. Each event gets a signature made of three parts: module, function and a normalized message, with numbers, paths, identifiers and dates removed. Events with the same signature go into one group with a counter.
That way "how many times did this happen" is counted the same way in every project and from every source. For a CI run the module is the repository and the function is the workflow name, and the message includes the outcome and the branch.
Classification and severity
Each group is classified as a real error, an external service or noise, by explicit rules. The default is "real", so that whatever was not recognized is not hidden. A CI run cancelled by hand is recorded as noise.
Severity (low, medium, high, critical) is computed from the number of occurrences in the last seven days:
- noise always stays low;
- an external service never goes above medium;
- a group marked as resolved that comes back goes up a level;
- a group that went quiet drops by itself, as its occurrences leave the window.
Severity set by hand overrides the calculation.
What happens to a group next
- An email about a new group, once per group and not per occurrence, and a separate email when a closed group comes back. Only for real errors, and only if the project has an alert address set; without one nothing is sent.
- A task from an error in one click. The task remembers which group it was born from.
- A resolution: a group can record how it was solved, and the error screen shows similar groups that have already been solved.
- Commits: when the stack trace identifies the class where the error failed, the latest commits that touched its file are shown.
The error text in the email and on the provider organization's screen has identifiers masked: an error message sometimes holds what the user typed, and an email that has gone out cannot be taken back.
What the customer sees, and what is not pulled
In the portal the customer sees one tile: how many groups of real errors are active right now, or that everything is fine. They do not see the list of errors itself. The provider organization sees the groups with masked text.
- The error tracker's own groups, notes and statuses are not pulled, and nothing is written to it.
- A successful CI run is not stored.
- A single event is kept for 30 days. The group and its counter remain after that.
Frequently asked questions
Which error trackers does SLAtech Vantage support?
Why are the groups different from the groups in Sentry?
Who gets an alert about a new error?
Does the customer see the errors?
Want to see errors from several tools in one list? You can start with a trial.
Start a free trial