Flarseo
This translation is being reviewed. The Italian text remains the reference version.
When something is broken, we say so
This page is not a live dashboard: it explains the process. What we treat as an incident, who we notify, how fast, and where to find the formal commitments we have put in writing.
What we treat as an incident
We call an incident any event that prevents or visibly degrades use of the platform for several customers at once. A problem affecting a single workspace is handled as a support request rather than an incident, even when it feels serious to the person living it.
We classify severity in three levels, and the level decides how urgently we act and how often we update the people affected.
| Level | What is happening | How we respond |
|---|---|---|
| Critical | The platform is unreachable, or content is not being published. | Immediate response and frequent updates until it is closed. |
| Significant | Part of the service is degraded: marked slowness, jobs queueing, an integration not responding. | Response within the working day and an update whenever the situation changes. |
| Minor | A contained defect with a workable alternative. | Fix planned with normal releases and reported in the changelog. |
A slowdown in an external service we depend on, for example a search engine or the site we publish to, is communicated the same way even when the cause is not ours: for you the effect is identical.
How you get told
No surprises and no silence: the information reaches you where you are already looking.
Notice inside the platform
The first place the message appears is your workspace: a banner at the top of the page that stays visible while the incident is open.
Email to those affected
For critical incidents, and for significant ones that drag on, we write to the account contact address. We do not send email for minor defects, so that the notice still means something when it matters.
Closure and summary
When the service is back to normal we say so explicitly. For critical incidents we also write what happened, what it affected and what we are changing so it does not happen again.
Scheduled work
Most updates ship without interrupting the service and without you having to do anything. When work does require a window of unavailability, we follow three fixed rules.
- The window is scheduled during low traffic hours, normally overnight in the Italian time zone or at the weekend.
- We tell you in advance, with notice proportionate to the expected duration and to the impact on work in progress.
- Jobs started before the window are not lost: they resume once the service is available again.
Urgent work without notice remains possible, but only to close a security problem or to prevent data loss. In that case we communicate during or immediately after the intervention, and we say why advance notice was not possible.
The formal commitments on availability, response times and priority live in the SLA document, not on this page. Here we describe the practice, there you find the text that governs.
What people ask us most
Seeing a problem right now?
Write to us describing what you see and since when. We answer within one working day, sooner if it is critical.