Service Level Agreement

A commitment that is not measured is not a commitment. This document turns our promises into numbers you can hold us to, and states plainly what we do and do not take on.

1. Service-level targets

These are service-level targets we commit to for subscribers, not past results. Exact scope is set in the SLA attached to each plan.

2. Incident priorities and response times

Priority	Definition	First response	Update cadence
Critical (P1)	Store fully down, orders cannot complete, or a suspected data breach	Within 4 hours	Every 4 hours until closed
High (P2)	A major function is broken with a temporary workaround available	Within 1 business day	Daily
Medium (P3)	A fault that does not block selling, or a change request within plan scope	Within 2 business days	On progress
Low (P4)	An enquiry or a suggested improvement	Within 3 business days	On completion

“First response” is the time until a specialist picks up the incident and replies with an initial diagnosis — not the time to full resolution, since repair time varies with cause and may depend on third parties.

3. Support window

• Standard support: Sunday to Thursday, 09:00–18:00 Saudi time, excluding public holidays.
• Critical incidents (P1): received around the clock, seven days a week, for plans that include this.
• Official channel: email to support@ezhalha.store. Reports arriving through unofficial channels are not counted in response-time calculations.

4. How availability is calculated

The 99.9% monthly availability target applies to the infrastructure we actually operate, and is measured by periodic external monitoring. The following are not counted as downtime:

• Scheduled maintenance announced at least 48 hours in advance and carried out in low-traffic windows.
• Outages at platform, hosting, network or payment-gateway providers.
• Outages caused by changes made by the client or someone acting for the client without coordinating with us.
• Exceeding the consumption limits agreed in the plan.
• Force majeure.

5. Backup and restore

• A full backup of files and database every 24 hours.
• Backups retained for at least 14 consecutive days.
• Periodic restore testing — because a backup whose restore has never been tested is not a backup.
• On a restore request we begin work within the response time for the matching priority.

6. The monthly report

You receive at least one written report each month covering: what was delivered during the month, the core performance indicators, incidents opened and closed with their response times, open risks, and the recommendation for the following month. It states what did not work as plainly as what did.

7. What support covers and what it does not

Covered: fault resolution, security updates, availability monitoring, backups, small changes within plan scope, and operational advice.

Not covered except under a separate agreement and price: new feature development, replatforming the store, content production and photography, third-party fees and advertising budgets, and faults caused by changes another party made without coordinating with us.

8. Remedy on failure

If we miss the availability target, or repeatedly exceed the critical-incident response time within a single month, you are entitled to a service credit applied against the next cycle in proportion to the shortfall, or a refund of the corresponding portion of fees. We calculate that credit and include it in the monthly report on our own initiative, without you having to ask.

9. Escalation

1. The specialist handling the incident.
2. The account owner — if response times are not met.
3. Management — by writing to support@ezhalha.store with “escalation” in the subject line.

10. Changes to this document

Any change that lowers the service level applies to existing subscribers only after at least thirty days’ notice, during which they may cancel without penalty. Changes that raise the service level take effect on publication.