Service Level Agreement
The availability target, service credits, support and recovery commitments that SSStudio gives for paid organizational plans of LeraLink.
Last updated: 12 November 2026
1. Scope and status
1.1 This Service Level Agreement ("SLA") forms part of the Customer Agreement between SSStudio, trading as LeraLink, and the Customer, where the Order Form says that it applies. It applies to paid organisational plans. It does not apply to a Pilot, unless the Order Form says otherwise.
1.2 Capitalised terms have the meaning given in the Customer Agreement. In addition:
| Term | Meaning |
|---|---|
| Covered Components | The parts of an Installation listed in clause 2.1. |
| Downtime | A period during which a Covered Component is Unavailable, as defined in clause 3.3, other than Excluded Time. |
| Excluded Time | Time excluded under clause 4. |
| Month | A calendar month, in the time zone Europe/Amsterdam. |
| Monthly Fee | The Fees for the affected Installation for the Month concerned; where Fees are invoiced annually, one twelfth of the annual Fees. |
| Support Hours | Monday to Friday, 09:00 to 17:00 Central European Time (CET, or CEST in summer), except public holidays recognised in the Netherlands under the General Extension of Time Limits Act (Algemene termijnenwet). |
| Business Hour | One hour within Support Hours. |
1.3 LeraLink is in a controlled pilot stage and one person operates the service. There is no 24/7 on-call. The commitments in this SLA are set so that they can be met in that situation; where something is done on a best-effort basis, this SLA says so.
2. Service scope
2.1 The Covered Components of each Installation are:
- the public site of the Installation, on its LeraLink address and on any domain of the Customer connected to it;
- the Studio, the writing environment of the Installation, including signing in, opening, saving and publishing Pieces;
- the installation administration.
2.2 The following are not Covered Components. SSStudio provides them with reasonable care, but the availability target does not apply to them:
- AI Features, which depend on models provided by others;
- the time within which an email (a sign-in code, a notification or a newsletter) reaches the recipient's inbox after SSStudio has handed it to its email delivery provider;
- source lookups at external services such as Crossref, OpenAlex, Open Library, Google Books, Wikidata, Wikimedia Commons and web search;
- the freshness of the search index;
- content from other services embedded in Pieces;
- features that the Documentation marks as being in preview;
- the status page status.lera.link itself;
- the Hub and SSStudio's own website, except where they are needed to sign in to the Installation.
3. Availability target and measurement
3.1 SSStudio's target is that each Covered Component of each Installation is available at least 99.5% of the time in each Month.
3.2 Availability for a Month is calculated per Installation as:
Availability % = (Total minutes in the Month − Excluded Time − Downtime) ÷ (Total minutes in the Month − Excluded Time) × 100
A period during which more than one Covered Component is Unavailable at the same time counts once.
3.3 A Covered Component is Unavailable when, for all or substantially all of its users:
- it returns server errors or does not respond within 30 seconds; or
- a core function fails: signing in, opening the public site, opening or saving in the Studio, publishing, or opening the installation administration; or
- SSStudio has placed the Installation, or the whole platform, in read-only mode or maintenance mode, outside announced planned maintenance and other than at the Customer's request, in which case the Studio and the administration count as Unavailable while the public site remains available.
Slowness that does not meet these conditions is not Downtime, but the Customer may report it as a P2 or P3 issue under clause 7.
3.4 Measurement. Availability is measured by:
- SSStudio's internal monitoring, which checks the platform from outside it about every 15 minutes, including the platform administration and the addresses of the Installations that SSStudio has added to it; the addresses of the Customer's Installation are added when the Order Form says that this SLA applies;
- the external status page status.lera.link, which runs on GitHub, independently of LeraLink, and shows the platform as a whole, not individual Installations;
- reports by the Customer, with the times and evidence the Customer has.
3.5 Downtime starts at the first failed check, or at the time the Customer reports Unavailability with evidence, if earlier, and ends at the first successful check after the cause is resolved. Because checks run about every 15 minutes, Downtime is counted in steps of about 15 minutes. Where the Customer's evidence and SSStudio's monitoring differ, SSStudio considers both in good faith and, in case of doubt, counts the period as Downtime.
3.6 For reference, 99.5% availability allows about 3 hours and 36 minutes of Downtime in a Month of 30 days; 99.0% about 7 hours and 12 minutes; 97.0% about 21 hours and 36 minutes.
4. Exclusions
4.1 Planned maintenance. Time during announced planned maintenance is Excluded Time, provided that:
- SSStudio announces it at least 48 hours in advance, by email to the Owners of the Installation, by a notice shown on LeraLink's sites and as an Announcement on the Hub, stating the expected start, duration and effect;
- planned maintenance does not exceed the number of hours in total in a Month stated in the Order Form; any further maintenance time in that Month counts as Downtime;
- SSStudio schedules it outside 08:00–20:00 CET/CEST wherever possible. Where possible, the Installation is placed in read-only mode during maintenance, so that it can still be read.
Maintenance that is not announced at least 48 hours in advance, including urgent maintenance to fix a security vulnerability, is not planned maintenance and counts as Downtime.
4.2 Other exclusions. Time is also Excluded Time when Unavailability is caused by:
- the Customer, its Authorised Users or its systems, including the Customer's network, devices, browsers and internet access, a misconfiguration made by the Customer, or the records of a Customer domain at the Customer's domain name provider;
- the Customer's request, for example to place the Installation in read-only mode;
- a suspension under clause 16 of the Customer Agreement;
- force majeure as defined in clause 23 of the Customer Agreement;
- a failure of the public internet outside Cloudflare's network between the user and Cloudflare, which neither party nor SSStudio's subcontractors control.
4.3 Failures of upstream providers count. A failure of Cloudflare, or of another subcontractor on which the Covered Components depend, counts as Downtime. It is not a general exclusion. It is Excluded Time only where the failure is itself caused by force majeure under clause 23 of the Customer Agreement, such as war or a natural disaster, or where the Customer's own systems cause it.
4.4 The reason for this position: SSStudio chose these providers, and the Customer cannot influence that choice. Under Dutch law a party is in principle responsible for the auxiliaries it uses to perform an agreement (article 6:76 of the Dutch Civil Code), and the Customer Agreement does not treat a provider's failure as force majeure in itself. Because service credits are capped at 25% of the Monthly Fee and are the sole remedy for missing the availability target, carrying this risk is proportionate for SSStudio. SSStudio cannot restore the Covered Components independently of Cloudflare during a Cloudflare outage; it will keep the Customer informed under clause 9.
5. Service credits
5.1 If availability of an Installation in a Month is below the target, the Customer is entitled to a service credit:
| Availability in the Month | Service credit |
|---|---|
| Less than 99.5%, and at least 99.0% | 5% of the Monthly Fee |
| Less than 99.0%, and at least 97.0% | 10% of the Monthly Fee |
| Less than 97.0% | 25% of the Monthly Fee |
5.2 The total of service credits for one Installation in one Month is at most 25% of the Monthly Fee.
5.3 Claim. The Customer claims a service credit by email to support@lera.link within 30 days after the end of the Month concerned, naming the Installation and, where it has them, the dates, times and evidence of the Downtime. SSStudio responds within 10 Business Days with its own measurement. SSStudio may also grant a credit on its own initiative when its monitoring shows the target was missed.
5.4 A service credit is deducted from the next invoice. It is not paid out, except that a credit outstanding when the Order Form ends is paid to the Customer within 30 days.
5.5 Sole remedy. Service credits, together with the right to terminate in clause 5.6, are the Customer's sole and exclusive remedy for a failure to meet the availability target. This does not limit the Customer's rights under the Customer Agreement or the Data Processing Agreement for other failures, such as a personal data breach or a loss of data.
5.6 Termination for repeated failure. The Customer may terminate the Order Form for the affected Installation by written notice with 30 days' effect if availability of that Installation is:
- below 99.0% in any three Months within a period of six consecutive Months; or
- below 97.0% in two consecutive Months.
The Customer must give notice within 60 days after the end of the last Month concerned. No fee for early termination applies, Fees paid in advance for the period after termination are refunded, and clause 18 of the Customer Agreement (exit and switching) applies.
6. Support
6.1 Channels. Support is given by email:
| Topic | Address |
|---|---|
| Support requests and incidents | support@lera.link |
| Security incidents and vulnerabilities | security@lera.link |
| Privacy and personal data breaches | privacy@lera.link |
For a P1 issue, the Customer puts "P1" at the start of the subject line. Support is available in English and Dutch; Persian is also possible.
6.2 Support Hours. Support is given during Support Hours: Monday to Friday, 09:00 to 17:00 CET/CEST, except public holidays recognised in the Netherlands.
6.3 Outside Support Hours. There is no 24/7 on-call during the pilot stage. Outside Support Hours, the internal monitoring alerts the operator to failures of the platform and of Installations, and the operator acts on P1 issues on a best-effort basis. No response target applies outside Support Hours.
6.4 Planned absence. One person operates the service. A planned absence of the operator is announced to the Owners in advance, as stated in the Order Form. During such an absence, the arrangement and the response targets stated in the Order Form apply.
6.5 Who may ask. Support requests are accepted from the Owners and administrators of the Installation and from the contacts named in the Order Form. Authorised Users with other roles ask their Installation's administrators first.
7. Priorities and response targets
7.1 Priorities. The Customer proposes a priority when it reports an issue. SSStudio may set a different priority, and explains why.
| Priority | Definition | Examples |
|---|---|---|
| P1 Critical | A Covered Component is Unavailable, or there is a security incident, a suspected personal data breach, or loss or corruption of Customer Content; no workaround exists. | The public site does not load; no one can sign in; content has disappeared. |
| P2 High | A core function fails or is seriously degraded for many users, and the workaround is limited. | Publishing fails; a newsletter cannot be sent; the Studio is very slow for everyone. |
| P3 Normal | A function does not work as the Documentation describes, for some users, and a workaround exists; or a defect hinders use without blocking it. | One kind of block does not display correctly; an export fails for one project. |
| P4 Request | A question, a configuration request, a request for information or documentation, or a suggestion. | How to set up a venue; a request for the statement of models used by the Installation. |
7.2 Response targets. A response is a first reply by a person that confirms receipt, states the priority and states the next step. It is not a resolution. Response targets run only during Support Hours.
| Priority | Response target | Updates until resolved or worked around |
|---|---|---|
| P1 Critical | 4 Business Hours | At least every 4 Business Hours |
| P2 High | 1 Business Day | At least every Business Day |
| P3 Normal | 3 Business Days | When there is progress |
| P4 Request | Best effort | — |
For example, a P1 issue reported on a Friday at 16:00 has a response target of Monday at 12:00. In practice, SSStudio aims to respond to a P1 issue as soon as the operator is alerted, also outside Support Hours, but does not commit to this.
7.3 Resolution. SSStudio does not commit to fixed resolution times. It works on a P1 issue without interruption during Support Hours until the issue is resolved or a workaround is in place, and on P2 and P3 issues with the priority they have.
7.4 Personal data breaches. The notification period for a personal data breach is not a response target under this clause and does not depend on Support Hours. SSStudio notifies a personal data breach affecting Customer Personal Data without undue delay and in any case within 48 hours of becoming aware of it, as the Data Processing Agreement sets out.
7.5 Missing a response target does not give a right to a service credit. If SSStudio repeatedly misses the response targets, the Customer may raise this in the review under clause 11, and it may be a material breach under clause 17.3 of the Customer Agreement.
8. Recovery objectives
8.1 SSStudio makes a logical backup of the whole database every night, kept for 30 days in Cloudflare's European Union storage, and uses Cloudflare's point-in-time restore for the databases. Restoring is a tested procedure: measured on a copy of production on 31 October 2026, restoring the database took 24 minutes, and the move of the platform to the European Union on 3 November 2026 was itself a full restore. Restores are rehearsed on a separate copy.
8.2 The recovery objectives are:
| Scenario | Recovery point objective (RPO) | Recovery time objective (RTO) |
|---|---|---|
| Total loss of the database | Up to 24 hours: the last nightly backup | Target for full restoration of the platform: as stated in the Order Form |
| Destructive change to data, for example an erroneous mass deletion | The moment before the change, by point-in-time restore | Target for the platform: as stated in the Order Form; for a single Installation, see clause 8.3 |
| Loss of the platform's runtime or configuration | No loss of data | Target: as stated in the Order Form, by redeploying the released version |
| Outage of Cloudflare | No loss of data expected | Depends on Cloudflare; counts as Downtime under clause 4.3 |
8.3 Point-in-time restore applies to the database as a whole. Returning one Installation to an earlier point, without affecting others, is done by restoring a separate copy and transferring the affected records. That takes longer; SSStudio agrees the time with the Customer when it occurs.
8.4 The restoration time target stated in the Order Form allows for the measured database restore of 24 minutes, for verification that every table is complete, for redeployment and for checks before the Service is opened again. It is a target, not a guarantee. Time during which a Covered Component is Unavailable while it is being restored counts as Downtime.
8.5 Files (images, audio and documents) are stored redundantly by Cloudflare's file storage but are not separately backed up. A file that a person deletes is removed at once and cannot be restored by SSStudio. The Customer can keep its own copies with the export functions of the Service.
9. Incident communication
9.1 Platform-wide incidents are shown on status.lera.link.
9.2 Incidents that affect the Customer's Installation at P1 level are communicated by email to the Owners and to the support and security contacts named in the Order Form, as soon as SSStudio has confirmed the incident and within the P1 response target, with updates as set out in clause 7.2.
9.3 Incident reports. For every P1 incident, SSStudio publishes an incident report in Updates → Incident Reports on the Hub within 10 Business Days after the incident is resolved. The report states what happened, when, what was affected, the cause as far as known, what was done, and what will be done to prevent recurrence. It contains no information that would help an attacker or that identifies a customer without its consent.
9.4 Personal data breaches are notified as the Data Processing Agreement sets out.
10. Reporting
10.1 On request, SSStudio sends the Customer an availability report for its Installation for a Month within 10 Business Days after the request, or after the end of the Month if that is later. The report states the measured availability, the Downtime periods and their causes, the Excluded Time and the service credits that apply.
10.2 On request, SSStudio sends a summary of the support requests of the Installation in a period, with their priority and response times.
11. Review and changes
11.1 On request, and at least once a year for each Subscription, the parties review the operation of this SLA: availability, support, incidents and planned improvements.
11.2 SSStudio may change this SLA with at least 30 days' notice, as described in the Change Notification Policy. A change that reduces the commitments of this SLA does not apply to a running Subscription Term; it applies from the next renewal.
11.3 SSStudio expects to strengthen these commitments as the service moves beyond the pilot stage, in particular the support arrangements. An improvement can apply at any time.
12. Customer cooperation
The Customer reports issues promptly, through the channels in clause 6.1, with the information it has (what happened, when, which addresses or Pieces, any error messages), keeps the contacts in the Order Form up to date, and gives the cooperation reasonably needed to resolve an issue.