Service Level Agreement (SLA)
What availability we commit to, how we measure it, what is excluded and what happens if we miss it.
This is a courtesy translation. The binding version of this agreement is the Spanish one: Acuerdo de Nivel de Servicio. If the two texts differ, the Spanish version prevails.
Last updated: 2026-08-18
This agreement describes the service level we commit to for Nirby: Foreby (from here on, “Nirby”): what availability you can expect from us, how it is measured, what is excluded from the calculation and what you are entitled to if we fall short. It forms part of the Terms and conditions and is read alongside the Support policy.
Who it applies to
- Paid plans (Pro, Max and custom agreements): everything that follows applies.
- Free plan and test environments: provided as is, with no availability commitment and no compensation. We use them ourselves to try things out.
- If you signed a contract or a service order with different terms, that document governs.
What we mean by each thing
- Service: the admin application, published Forms and the Sales Rooms reachable by their links.
- Monthly availability: the percentage of minutes in the calendar month during which the Service responds correctly to requests, over the total minutes of the month, minus the exclusions below.
- Unavailability: the Service does not respond, or returns server-side errors, in a generalised way — not for a single Workspace, a single browser or a single action.
- Degradation: the Service works but is slow, or one specific feature is affected. It is handled as an incident (see severities) and does not count as unavailability.
- Scheduled maintenance: a window announced in advance during which the Service may be interrupted.
Availability commitment
| Plan | Committed monthly availability |
|---|---|
| Free | No commitment (best effort) |
| Pro | 99% |
| Max | 99% |
| Custom | Whatever the contract sets |
The commitment is assessed per calendar month and per Workspace.
How we measure it
We measure from our own monitoring, with periodic automated checks against the Service using UptimeRobot. A period counts as unavailable when those checks fail consecutively for more than 5 minutes.
If your measurement does not match ours, write to us: we compare records before treating anything as settled.
What is excluded from the calculation
The following do not count as unavailability:
- Scheduled maintenance announced per the next section, nor emergency maintenance needed to protect the security or integrity of data.
- Outages caused by force majeure or by events outside our reasonable control.
- Failures of your infrastructure, your network, your browser or third-party services you connect.
- Suspension of the Service for non-payment or for a breach of the Terms.
- Use of the Service outside what the Terms provide for, including load generated by automations that were not agreed.
- Test environments, features marked as beta, and the free plan.
- The unavailability of an artificial intelligence model provider, as far as it affects only the features that depend on it. See “About artificial intelligence”.
Maintenance
- Scheduled: we give at least 48 hours’ notice, by email or inside the application, and we try to place it in the lowest-usage window.
- Emergency: when there is a security or data-loss risk, we act immediately and let you know as soon as we can, during or afterwards.
Incidents: severity and times
We assign severity by real impact, and it can change as the incident develops.
| Severity | What it means | First response* | Updates |
|---|---|---|---|
| Critical | The Service is unavailable, or published Forms cannot receive answers | 4–12 hours | every 4–12 hours |
| High | A main feature does not work and there is no way around it | 8–24 hours | every 8–24 hours |
| Medium | A feature fails but there is a workable alternative | 16–48 hours | On request |
| Low | Minor or cosmetic defect, or a question | 24–72 hours | On request |
Response times are exactly that: when we reply and start work. We do not commit to a resolution time, because it depends on the cause; we do commit to keeping you informed until it is closed.
- The first response is given in business hours, per the support schedule and the corresponding plan. More in our Support policy.
How to report an incident, in what hours and with what details: Support policy.
Compensation
If in a given month we do not reach the availability committed for your plan, you are entitled to request a service credit:
| Availability for the month | Credit against the monthly amount |
|---|---|
| Below your plan’s commitment and at or above 97.0% | 10% |
| Below 97.0% and at or above 95.0% | 25% |
| Below 95.0% and at or above 90.0% | 50% |
| Below 90.0% | 100% |
How much downtime the commitment tolerates, so the percentage means something: in a 30-day month — 43,200 minutes — 99% allows up to 7 hours and 12 minutes of accumulated unavailability. Beyond that there is a credit, and the following bands are 21 h 36 min (97%), 36 h (95%) and 72 h (90%).
Credit rules:
- It is requested by writing to support@nir.by within 30 days of the end of the affected month, stating the dates and times of the outage. After that, the credit for that month lapses.
- We reply within 10 business days with our availability calculation for the month. If it does not match yours, we compare records before closing anything.
- It is applied as a discount on the next invoice; it is not paid in cash, not exchanged for other services and not transferred to another customer.
- Credits for the same month do not stack: the highest applicable band applies, even if several incidents occurred.
- The maximum credit for a month is 100% of that month’s monthly amount.
- It only applies to paid plans and accounts in good standing. A month in which the Service was suspended for non-payment generates no credit.
- If you pay in advance for a period longer than a month, the monthly amount is calculated by prorating what was paid across the months covered.
- The credit is the sole remedy for missing the committed availability, without prejudice to anything the law does not allow to be excluded.
Backups and recovery
We keep periodic backups of the database and of stored files, with a retention period and a backup frequency that let us restore the Service in the event of a disaster; both vary and depend on the provider (Google Cloud Platform, Supabase and others). In the event of a serious incident, our objectives are to recover the service within 4 hours and with a maximum data loss of 24 hours.
These backups exist so we can recover from a disaster. They do not replace your own exports: if you delete content from the application, the intended way to get it back is not to ask us for a restore.
About artificial intelligence
This agreement covers the availability of the Service, not the accuracy of what it generates. The questions, analyses and documents the AI produces are assistance, may contain errors and must be reviewed before being used — as the Terms say.
Features that depend on an external model provider may degrade if that provider fails. In that case we work to restore them and we keep you informed, but unavailability attributable to that provider is excluded from the availability calculation.
Changes to this agreement
If we update it, we will change the date in the header. When a change reduces a commitment, we will give you at least 30 days’ notice and it will not apply to a period already invoiced.
Contact
Nirby SpA · 2 Oriente 124, Oficina 205, Edificio 02, 2340000 Viña del Mar, Chile · Contact email for incidents and credits: support@nir.by