Service commitment

This document describes the level of service at which we operate Zetta: what we watch, what target we set ourselves, when we do maintenance, how we back up the data and how long we take to respond to a support request.

The components we monitor are:

• The ERP web application and the API behind it.
• Each company's PostgreSQL database.
• The online stores and the customer portal.
• The AFIP integration and the Mercado Pago integration, in the part that depends on us.
• Transactional email delivery.
• The corporate website.

The monthly availability target for the application and the API is 99.5 %, excluding maintenance windows announced in advance and outages caused by third parties.

Monthly target

99.5 %

Margin that implies

3 h 36 min in a 30-day month

Measurement window

Calendar month, Argentina time

Excluded from the calculation

Announced maintenance and third-party failures

It is an operational target, not a contractual guarantee with automatic penalties. If the service owner decides to add credits for missing it, they will be added to this document and announced.

We count as unavailability the time during which the application or the API does not respond, or returns an error, for all companies or for an entire company. It is measured with the service's automatic checks and with the platform's centralised logs.

The following do not count as unavailability:

• Maintenance windows announced in advance.
• Failures of third-party services: AFIP, Mercado Pago, Cloudflare, Vercel or the email provider.
• Connectivity, local network or equipment problems on the user's side.
• Security lockouts triggered by the behaviour of the account or the IP itself.
• Force majeure events.

Routine updates are deployed without interrupting the service. When a task does require an interruption —a heavy database migration, an infrastructure change— we use a scheduled window.

Usual hours

From 00:00 to 06:00, Argentina time

Advance notice

By email, at least 48 hours ahead

Who is notified

The responsible users of each company

Publication

Also at /estado

An emergency intervention for a security problem may be carried out without prior notice. In that case we notify as soon as the system is stable and explain what happened.

• Frequency: one full copy per day, in the early hours.
• Encryption: each copy is encrypted with age and the private key does not live on the server, so whoever gains access to the server cannot read the backups.
• Where: in a bucket separate from the one the application uses.
• Retention: 7 daily copies and 35 days of weekly copies.
• Testing: one test restore per week. A backup that has never been restored is not a backup.

RPO — maximum data loss

24 hours

RTO target — recovery time

8 hours from the decision to restore

The RPO follows from the daily frequency: in a full restore, whatever was entered since the last backup is lost. The RTO is a target, not a guarantee: it depends on the size of the data and the cause of the incident.

Support is handled by email at hola@zetta.ar, Monday to Friday from 9 to 18, Argentina time, except national holidays. Outside those hours we handle critical incidents on a best-effort basis.

The times in the table are targets for a first response from a person, not for resolution: the time to a fix depends on the cause.

Write to hola@zetta.ar. The more precise the report, the faster it gets resolved:

1. The company and user you were operating with.
2. Which screen or operation you were carrying out.
3. What you expected to happen and what happened.
4. The approximate date and time, and the exact text of the error if one appears.
5. Whether it happens to a single person or to the whole company.

When an incident affects several companies, we publish it at /estado and notify the responsible users by email.

Part of what Zetta does depends on third-party services. When one of them fails, we inform you and stay with you, but we cannot resolve it:

• AFIP: its authentication and electronic invoicing services have outages and windows of their own. Without AFIP there is no CAE, and that is not a failure of Zetta.
• Mercado Pago: availability of the checkout, of payment notifications and of the crediting of funds.
• Cloudflare and Vercel: network, traffic protection and hosting of the front ends.
• Email provider: delivery of transactional email and how it is classified in the recipient's inbox.
• Customer connectivity: internet, local network and the company's equipment.

Where the operation can continue another way —for example, leaving the document as a draft and issuing it when AFIP is back— the system allows it and support guides you.

When we miss the target in a given month, we commit to:

• Informing the affected companies, without waiting to be asked.
• Sending a written analysis within 5 business days of the incident being closed: what happened, why, what was done and what changes so it does not happen again.
• Publishing the incident at /estado.

We may update this commitment as the infrastructure and monitoring tools change. The date of the last update appears at the top.

If a change lowers the committed level —a lower target, a wider window, a longer response time— we notify you by email at least 30 days in advance. The general terms of the service are in the terms and conditions.