SLA — Service Level Agreement

The contractual SLA terms appear here; the public summary lives at /en/security/sla. This document is the legally binding version once incorporated as an exhibit to the Enterprise contract signed between the parties.

1. Availability commitment

P4 Software ("the company") commits to 99.9% monthly availability of each customer tenant's application plane and public API. That availability translates to roughly forty-three minutes of unplanned downtime per calendar month, maximum. Measurement is performed by external synthetic probes that validate a basic authenticated read transaction against documented endpoints.

2. Definition of downtime

"Downtime" means any continuous period in which external probes cannot complete a basic authenticated read transaction against the tenant for more than sixty consecutive seconds. Measurement is aggregated minute by minute and published on the status page. Downtime is attributed to the calendar month in which it occurs.

3. Tiered credit table

If monthly availability falls below the commitment, the customer is entitled to the following credit against the affected tenant's monthly charge:

• Tier 1 — ≥ 99.9%. 0% credit. SLA met.
• Tier 2 — < 99.9% and ≥ 99.0%. 10% credit on the monthly charge.
• Tier 3 — < 99.0% and ≥ 95.0%. 25% credit on the monthly charge.
• Tier 4 — < 95.0%. 50% credit on the monthly charge.

The aggregate cap per month is 50% of the affected tenant's monthly charge, even if multiple incidents occur in the same period. The credit is applied as a discount on the next invoice issued to the customer.

4. Maintenance window

Scheduled maintenance announced at least seventy-two hours in advance to the customer's administrative contact does not count as downtime for purposes of this SLA. The scheduled maintenance window is capped at four hours per calendar month and is executed outside the tenant's local business hours when operationally feasible. Emergency maintenance to mitigate critical security vulnerabilities may be executed with shorter notice, with after-the-fact notification and an incident report.

5. Exclusions

The following events are not counted as downtime for credit calculation:

• Scheduled maintenance announced with the notice established in section 4.
• Force majeure including natural disasters, armed conflict, regulatory authority decisions and outages of upstream providers outside the company's reasonable control.
• Microsoft Azure upstream outages reported by Microsoft as regional or global incidents on the official Azure status portal.
• Customer actions including changes to customer-controlled DNS, customer-initiated credential revocation, network or firewall changes blocking endpoints, and use outside the documented public API parameters.
• DDoS attacks targeting the customer tenant that are not part of a generalized platform incident.

6. Credit-claim procedure

To claim the corresponding credit, the customer must open a formal ticket through the designated Customer Success channel within thirty calendar days of the close of the affected month. The ticket must include the claimed downtime period and the reference to the incident published on the status page, where applicable.

Customer Success correlates the claim with external probe data and the internal incident log. Validation is completed within fifteen business days of ticket receipt. The approved credit is applied as a discount on the invoice for the following cycle. Claims submitted outside the thirty-day window are not processed.

7. Quarterly report

The company issues a quarterly audit report to Enterprise customers that includes actual availability measured per tenant, incidents reported during the quarter, status of applied credits and references to audited SOC 2 controls. The report is delivered to the designated administrative contact within thirty days of the quarter's close.

8. Exclusive remedies

The tiered credit described in section 3 is the customer's exclusive and total remedy for breach of the availability commitment. The customer expressly waives any other compensatory remedy for SLA breach, without prejudice to the general termination rights for sustained breach established in the master agreement.

9. Changes to the SLA

Material changes to this SLA are communicated to active Enterprise customers at least thirty days in advance. No change reduces availability commitments or credit tiers during a customer's already-agreed contractual term, except by express written agreement.