Service level agreement
This agreement covers Eriksen Labs apps distributed through the Atlassian Marketplace. It sets out what we commit to, in terms we can actually meet.
Support hours
Support is provided through our support portal and by email at support@eriksenlabs.com, Monday to Friday, 09:00–17:00 Central European Time, excluding Norwegian public holidays.
The response targets below apply to both channels. Requests raised in the portal can be tracked to resolution.
Requests received outside these hours are treated as arriving at the start of the next business day.
Response targets
The targets below are for our first substantive response, measured in business days. We deliberately do not promise fixed resolution times, because the cause of a defect is not known when it is reported. We do commit to keeping you updated until it is closed.
P1 — Critical
App unusable for all users, or customer data at risk.
Within 1 business day.
P2 — Major
A significant feature is broken; a workaround exists.
Within 2 business days.
P3 — Minor
Cosmetic issues, questions, feature requests.
Within 3 business days.
Security
Suspected vulnerabilities are triaged ahead of all other work.
Within 1 business day.
Availability
Our apps run entirely inside Atlassian's infrastructure on Atlassian Forge. We operate no servers of our own, so there is no separate service that can go down, and app availability follows the availability of your own Atlassian site.
For that reason we do not publish an uptime percentage. Committing to one would mean committing to Atlassian's uptime on their behalf, which we are not in a position to do.
Escalation
If a request has not been answered within its target, comment
ESCALATE on the request in the
support portal,
or reply to the existing email thread with ESCALATE in
the subject line. Escalated requests are reviewed the same business
day.
What this does not cover
This agreement does not apply to what it does. That product has no uptime for us to commit to: the scanner runs on your machine and the pull request check runs inside your own CI runner. There is no service of ours for it to depend on, so promising availability would be inventing an obligation rather than accepting one.
The Action is built so that a scan error does not block your
pipeline: the check passes and says so in the log, and a finding
fails the check only if you turn on fail-on-new. The
Action still depends on its runtime, its dependencies and GitHub's
infrastructure being available. Support for the product is through our
support portal
and by email, on the same terms as everything else here.
Scope
This agreement covers:
- Defects and unexpected behaviour in our apps
- Installation, licensing and configuration questions
- Security reports
It does not cover:
- Confluence or Jira itself, or Atlassian platform incidents
- Third-party apps, even where they interact with ours
- Authoring content on your behalf
- Custom development or feature work to order
Changes
If these terms change we will update the date at the top of this page. Reductions in commitment will be announced at least 30 days in advance.