Support and Availability Policy - RegisterBench (DORA RoI Builder)

Version 1.0, in force from 2026-09-28

1. Scope and nature of this document

This Policy describes how support for the RegisterBench service is provided, what our availability target is, and how that target is to be measured and reported. It is the document that the Terms of Service and the Refund Policy refer to as the Support and Availability Policy.

This Policy is informational. Every time and every availability figure in it is an operational target that we pursue with due care on a best-effort basis. In version 1 of the service no target in this Policy is a contractual service level: missing a target gives rise to no contractual sanction, no flat-rate compensation and no service credit.

Relationship to the Refund Policy: the response-time targets of section 3 have no link to the Refund Policy and do not by themselves found any refund. The availability target of section 4 is referred to by the Refund Policy in one sentence, quoted here word for word: "Beyond the rule above, a pro-rata refund is granted only where the service was documented as unavailable below the target of the Support and Availability Policy." This Policy adds no refund rule to that sentence and changes nothing in it. What counts as documented unavailability is defined in section 4.

2. Support hours and channel

Support hours are business days, Monday to Friday excluding public holidays in Poland, from 9:00 to 17:00 Central European Time (CET/CEST).

Support requests are made by e-mail to support@registerbench.com.

We do not provide telephone support, live chat or round-the-clock (24/7) support. Outside support hours we make no commitment as to response: the response-time targets of section 3 do not run outside support hours, and a request received outside support hours is handled from the start of the next support hours.

3. Response-time targets

The following targets are operational targets measured in business hours, that is in hours falling within the support hours of section 2:

For a request received outside support hours the targets start running at the beginning of the next support hours.

These targets are best-effort operational targets. Missing a target gives rise to no sanction and has no link to the Refund Policy (section 1).

4. Availability target and its measurement

The availability target of the service is 99.5 per cent in a calendar month, excluding maintenance windows (section 6) and the events listed in section 5.

The target is, in the words of the Terms of Service, "an operational target of 99.5 per cent, communicated as a target and not as a contractual service level with penalties in version 1". It is an obligation of due care pursued on a best-effort basis. Missing it gives rise to no contractual sanction, no flat-rate compensation and no service credit in version 1.

Availability is measured by our own monitoring (uptime-kuma) running on a host independent of the production environment. That monitoring has been in operation since 2026-09-07 (plan item S-D11) and keeps its own history of the measurement.

The measurement is a sample and not a continuous observation, and this Policy says so rather than leaving it to be assumed. The monitoring probes the health endpoint of the service once every 60 seconds. An interruption shorter than that interval can fall between two probes and leave no record, and an interruption that leaves no record is not counted as unavailability under this Policy or under the Refund Policy. Restarts of the production hosts caused by automatic security updates (section 6) are of that order of length. We do not shorten the interval in order to catch them, because no practical sampling interval would reliably catch an interruption of a few seconds, and a shorter interval would create an appearance of precision the measurement does not have.

Documented unavailability. Once the public status page of the service is live, unavailability will be documented by an incident entry on that page, and only the period covered by such an entry will count as documented unavailability for the purpose of this Policy and of the Refund Policy. The status page is not live on the date of this version of the Policy. Once it is live, its address will be given in this Policy and on the website.

5. Exclusions

The following interruptions do not count towards unavailability:

1. force majeure,
2. failures on the side of the client's own suppliers (connection, hardware),
3. acts or omissions of the client,
4. attacks on the infrastructure, to the extent that we exercised due care,
5. maintenance windows (section 6).

6. Maintenance windows

Planned maintenance is scheduled outside typical working hours, that is outside 9:00-17:00 Polish time (CET/CEST) on business days, and is announced at least 24 hours in advance by e-mail to the address of the account - unless an urgent fix (security, failure) requires immediate action. Once the status page is live, the announcement will also be published on that page.

Automatic security updates and the restarts they cause. Security updates are installed on the production hosts automatically, and some of them require the host to be restarted. Such a restart cannot be announced 24 hours in advance, because the need for it only arises on the night the update is installed. It is placed outside working hours, at a fixed night hour set separately for each host so that the hosts do not restart at the same time. Such a restart is a temporary interruption of availability in connection with an update, which we may carry out without the announcement of the first paragraph of this section. It counts as a maintenance window for the purposes of sections 4 and 5.

Maintenance windows do not count towards unavailability (section 5) and are excluded from the availability target (section 4).

7. ICT incidents concerning the service

Assistance with an ICT incident related to the service is included at no additional charge (0 EUR). Such assistance is requested through the support channel of section 2.

How we work on incidents. The operational blueprint of the service provides for an incident runbook with three severity classes, SEV1, SEV2 and SEV3, and for a SEV1 incident for the following sequence: confirmation of the incident from two sources, an entry on the status page within 10 minutes, mitigation according to the procedure, a closing communication and a public post-mortem within 24 to 48 hours. The status page named in this sequence is not live on the date of this version (section 4). This paragraph describes how we intend to work. It is not a commitment, and none of the times in it is a target of this Policy. The classes mean: SEV1 - the service is unavailable to many clients, data is lost or at risk, or a security incident has occurred. SEV2 - a significant degradation: a main function of the service does not work and there is no workaround. SEV3 - everything else: questions, minor errors with a workaround, suggestions.

8. Seasonality - for information

The priority we give to an event depends on the reporting calendar of our clients. Our operational planning distinguishes three seasons: crunch from 1 February to 30 April, ramp from 1 November to 31 January, and quiet from 1 May to 31 October.

For the highest internal alerting priority (P1 - the class of the alerting matrix that covers, among others, the application or API being down and the database being down) the planning sets the following reaction and restoration targets per season. These targets are "communicated as targets, not as a contractual SLA with penalties". Crunch: reaction under 30 minutes between 7:00 and 23:00, restoration under 4 hours. Ramp: reaction under 2 hours, restoration under 8 hours. Quiet: reaction within business hours, restoration under 24 hours.

These seasonal figures are informational targets of our own operational planning. They are not contractual service levels and they have no link to the Refund Policy. The response-time targets that apply to support requests are those of section 3 only.

9. Changes to this Policy

We announce changes to this Policy 30 days before they take effect, with the same notice period as changes to the Terms of Service and to the Privacy Policy.