Applies to every BeryX plan: Free, Team, Business and Enterprise. It explains how to ask for help, when we reply and what to expect from maintenance and deprecations. Last reviewed: 29 September 2026.
This policy is not a service-level agreement (SLA). The first-response times below are targets that BeryxTech commits to. No plan includes an SLA with service credits by default; an SLA only binds BeryxTech when it is part of a signed contract (Terms of Service, section 5). Enterprise-specific terms, such as per-severity times, a dedicated channel and service health reports, are set out in each customer's contract.
1. Channels
- In the app, the "Request help" button. It is in the sidebar and on the Help page. You enter a subject, a
category and a description. The request reaches the support team with automatic technical context: the workspace
identifier, the plan, the app version, the page you were on, the language and the browser. It never carries data
from your sources. You get a request number (
sup_…) for reference. The reply reaches your account email. - Email: suporte@praxis.lbostuff.tech. Write from your account email. This channel works even when you are signed out.
- Security vulnerabilities: use the security contact published at
/.well-known/security.txtand on the Security page of the website. Do not use general support for this. - Data protection (GDPR): privacidade@praxis.lbostuff.tech.
2. Hours
Support works on business days, Monday to Friday, from 09:00 to 18:00 Lisbon time. It does not work on Portuguese national holidays. A request that arrives outside these hours joins the queue. The response time starts counting at the start of the next business period.
3. First-response time by plan
| Plan | First response |
|---|---|
| Free | Best effort, no guaranteed time |
| Team | Within 1 business day |
| Business | Within 4 business hours |
| Enterprise | As set in the contract |
The first response comes from a person on the team. In it we confirm we have the request and give a first assessment or ask for the information we still need. It is not the resolution time. The times only count within the hours in section 2. The plan that applies is the one in force in the workspace when the request is made; during a trial, it is the trial plan.
4. Severities
| Severity | When | Examples |
|---|---|---|
| S1: critical | The service is unavailable or data security is at risk, with no workaround | The app or the API do not respond for the whole workspace; suspected unauthorised access |
| S2: high | A core feature fails and there is no reasonable workaround | No scan runs; alerts have stopped arriving |
| S3: normal | A feature partly fails, or there is a workaround | A connector fails on one source; a report takes longer than usual |
| S4: low | Usage questions, feature requests, documentation | "How do I set up…?"; suggestions |
The support team sets the severity at triage, from the description. Describe the impact so the triage is right. On the Free, Team and Business plans, the times in section 3 apply to every severity, and S1 and S2 requests are handled first. Different times per severity only exist on Enterprise, by contract.
5. What to include in a request
- What you were trying to do and what happened, with the exact error message if there is one.
- When it happened, with date, time and time zone, and whether it happens again.
- Where it happened: the app page and the name of the dataset, rule or connection. Only give the name if you can share it.
- The impact: how many people or processes are affected and whether there is a workaround.
- For the API: the method and path, the HTTP status, the time in UTC, the
X-Request-IDheader of the response and the response ofGET /version. Never send the token.
Never send passwords, tokens, API keys or personal data from your sources. If we need to look at your workspace, we request support access. That access is read-only, has a time limit and only starts when an admin of your workspace approves it.
6. Planned maintenance
Most updates need no maintenance window. An intervention may interrupt or degrade the app, the API or the scans. In that case we announce it by email to workspace admins at least 5 business days in advance, with the date, the time and the expected duration. We carry it out outside support hours, preferably between 20:00 and 23:00 Lisbon time.
Urgent security fixes may require an intervention without prior notice. In that case we communicate it as soon as possible.
7. Feature deprecation
Removing a feature of a paid plan, or changing it in an incompatible way, requires at least 90 days' notice. The
notice goes by email to workspace admins and appears in the release notes (/datavault/changelog on the website). The public
API has its own, longer policy, with 180 days between the announcement and the removal
(API versioning). A legal obligation or a security risk may force a shorter period; in that
case the notice explains why.
8. Service status and incidents
The public status page is not published yet. When it is, the link will be in this section. Until then, incidents that affect the service are communicated by email to the admins of the affected workspaces. After an S1 incident, we send a summary of the cause and of the measures taken.
9. Changes to this policy
A change that reduces support, whether in channels, hours or response times, is announced by email to admins at least 30 days in advance. The date of the last review is at the top of this page.