Service Level Agreement

1.1 When this applies

This agreement applies only where a signed statement of work expressly incorporates it, and then only to the systems, environments and hours named in that statement of work. It does not apply to:

• work in progress before an agreement is signed;
• pre-sales questions, which are handled on a best-effort basis;
• free or unsolicited advice;
• any system, tier or environment not named in the statement of work — a staging environment is not covered merely because production is;
• anything governed instead by a dedicated or third-party agreement.

Where a statement of work says something different from this page, the statement of work wins.

1.2 What this is not

• It is not a guarantee of uptime. The availability figure in section 6 is a target. Service credits in section 8 are the remedy for missing it, and credits are a genuine and enforceable remedy — but a credit is a remedy, not a guarantee.
• It is not a support guarantee for third-party systems. If a defect originates in a vendor’s platform, a cloud provider, a payment gateway or an app store, our targets cover our investigation and our escalation, not the vendor’s fix.
• It is not an outcome guarantee. Nothing here promises a number of users, revenue, rankings or conversions.
• It is not evidence of any certification. WebNuvexa does not hold SOC 2 Type II or ISO 27001 certification and has not been audited by an independent assurance body. This page describes our own commitments and our own measurement. Where independent assurance matters to you, request current documentation from a qualified third party.
• It is not a substitute for the Terms of Service. Liability is limited by the Terms of Service, section 8, and credits are counted against that cap.

2.1 Hours

Standard support covers not yet confirmed: support hours and time zone. All response times in section 4 are measured against that window unless they say otherwise. A response target that runs in business hours does not require anybody to work a weekend.

Out-of-hours cover for P1 issues is not yet confirmed: on-call availability. Where 24/7 cover is not included, a P1 raised outside the support window is acknowledged at the start of the next business day, and we will say that plainly rather than pretending it is being worked on.

2.2 Channels

2.3 What to include in a report

A report that contains the following gets a useful first reply; a report that contains one line usually gets a request for information instead:

• What you expected to happen, and what happened instead.
• When it started, when you last saw it working, and whether it is intermittent or constant.
• Exact error message and any request or trace identifier.
• What you already tried, and what that produced.
• Steps to reproduce, if you have them.
• Business impact, in your words.

Screenshots or screen recordings help where the problem is visual. Please remove secrets — passwords, tokens, personal data — before sending anything.

2.4 What “response” means

A response is a first substantive reply from a person who has looked at the issue — not an automated acknowledgement, not a ticket number, and not a copied “have you tried a reboot”. A response can reasonably be “I cannot fix this yet, here is what I am doing next and when I will update you”. Telling you nothing would not be a response.

We assign severity on receipt. If you believe an issue has been under-classified, say so and give us the impact you are seeing — we will re-assess, and we will explain if we disagree.

3.1 Two rules about severity

• Severity can move in either direction. An issue we classified P3 becomes P1 the moment it is shown to be causing data loss. Equally, an issue you submitted as P1 that turns out to be a cosmetic problem in a rarely used screen will be re-classified, and we will tell you that and why rather than quietly leaving the clock running.
• Severity is not a negotiating position. Raising an issue to P1 to get a faster answer is a misuse of this document, and if it becomes a pattern it is a breach of the Acceptable Use Policy.

These are targets for a first substantive response as defined in 2.4. They are not targets for resolution, and they are not guarantees. A response target that has been missed is not automatically a service-credit event — credits are addressed in section 8, and they relate to availability.

Clock rules

• The response clock starts when the report reaches a channel listed in 2.2, not when we happen to open it.
• The clock pauses while we are waiting on you. If we have asked for a log, a credential, a decision or a reproduction and none has arrived, the elapsed time is not counted against the target. We will tell you that the clock has paused, so it never becomes a hidden excuse.
• Targets are measured in elapsed hours. Where a target is stated in business hours, business hours are those in section 2.1.
• A duplicate report, an auto-acknowledgement and a follow-up “any news?” do not each start a new clock. The clock is per incident, not per message.
• Where not yet confirmed: on-call availability excludes 24/7 cover, the P1 target applies during the support window and the issue is acknowledged at the next opening.

Response we can commit to. Resolution depends on the nature of the fault, whether it is ours, and whether a third party can fix it. The targets below are therefore deliberately weaker than the response targets, and are stated as targets for a fix or a documented workaround, not as a promise of a particular outcome.

Where these targets do not apply

The clock stops, and we will say so, where:

• The fault is not ours. A third-party platform, a certificate authority, a domain registrar, an app store review queue, a cloud provider or a payment gateway. Our commitment here is to identify the cause, escalate on your behalf, and keep you informed — not to control someone else’s fix.
• You hold something up. Access, a decision, content, approval, a third-party account, or information we asked for.
• The request is not really a fix. A new feature, a scope increase, or a change of requirement. That is a change request under the Terms of Service, section 2.3, and it gets quoted.
• The environment is unsupported. A version or provider we have deprecated, or a configuration outside the supported range.
• A force majeure event is affecting either party, as defined in section 10.

6.1 What we target

Where a statement of work names a production system and includes availability cover, the monthly availability target is not yet confirmed: uptime target, measured over each calendar month.

Availability is measured from outside, by automated request at a [MONITORING FREQUENCY, e.g. 1-minute] interval, from not yet confirmed: monitoring locations. Downtime is the period between the first failed check and the first successful check, rounded to the monitoring interval. Monitoring that is itself unavailable or misreporting is not downtime attributable to the service.

6.2 How we report

Availability reports are issued at not yet confirmed: reporting cadence and cover the previous period, with the raw check data available on request. Reports are produced from our own monitoring; they are not independently verified, and we do not describe them as third-party attestations.

Where monitoring itself fails, we will report the gap rather than infer availability from it.

6.3 The hosting dependency

Client systems are hosted with third-party infrastructure providers. For the public website, that provider is not yet confirmed: hosting provider. For a client system, the provider and region are named in the relevant statement of work.

Those providers have their own availability terms, their own maintenance windows and their own failures. When an outage originates upstream, our commitment is to detect it, communicate it, escalate it and use our own contractual remedies against that provider — not to warrant their uptime. If your business cannot tolerate that dependency, say so at contracting . It is a real risk and it should be priced and architected for explicitly, not absorbed silently.

7.1 Notice

Planned maintenance requires at least not yet confirmed: maintenance notice period written notice to the contacts named in the statement of work, stating what will happen, when the window is, the expected duration and its effect, and what you should do if anything.

Notice means written notice to a named contact, not a status page entry nobody is subscribed to.

7.2 Windows

Planned maintenance is carried out in not yet confirmed: maintenance window, and is scheduled to minimise disruption. Where a critical security fix cannot wait for that window, we may carry it out sooner; we will give as much notice as we can, and we will treat it as unannounced maintenance under 7.3 unless it was notified.

7.3 Emergency maintenance

Where a defect or security issue requires immediate action to protect a client, the public website or the wider internet, we may act without the notice period. We will notify affected clients as soon as is safe to do so, and we will provide a post-incident summary on request. Emergency maintenance does not attract service credits.

7.4 What we expect of you

If maintenance affects a client system we are changing on your behalf, we will agree a window with you and we will take a verified backup or snapshot first where one is technically available. We will roll back if the change does not behave as intended. Where you host the system yourself and we are patching it, we need the access and the authority described in the Terms of Service, section 3.1, and a change that has not been agreed with you will be a change request.

8.1 The only remedy for availability

If monthly availability falls below the target in section 6, your sole and exclusive remedy is a service credit against the fee for the affected system, calculated as below. Credits are applied to the next invoice, or paid on request where there is no further invoice.

8.2 Credit schedule

Credits are capped at [MAXIMUM CREDIT, e.g. 50%] of one month’s fee for the affected system, per calendar month. There is no rollover, no accumulation across months, and no credit for a system whose availability was not covered by this agreement in the first place.

8.3 Claiming

• Claims must be made in writing to hello@webnuvexa.com within [CREDIT CLAIM WINDOW, e.g. 30 days] of the end of the month in question. Claims made after that window are not eligible.
• A claim must identify the system, the month, and the monitoring data relied on. We will share our data so both sides are working from the same numbers.
• Where a claim is valid, we will confirm it in writing and apply the credit.
• Where a claim is disputed, we will provide the underlying check data, and the matter can be escalated under section 9.

8.4 What credits are not for

• Missed response or resolution targets in sections 4 and 5. Those are service commitments we report against; they do not generate credits. not yet confirmed: this clause needs rewriting to match the real SLA
• Downtime caused by the exclusions in section 10.
• Planned maintenance notified under section 7.1.
• Loss of business, revenue or data. Those are not recoverable as credits and remain subject to the limitation of liability in the Terms of Service, section 8.
• Previews, staging, sandbox, trial or development environments, unless the statement of work expressly includes them.

Credits count towards the aggregate liability cap in the Terms of Service, section 8.2. They are a form of remedy, not a separate pot of money.

Escalation is not an accusation and it is not a threat. It is the mechanism this document provides so that a problem you cannot get solved through the normal route has somewhere to go. You will not be penalised for using it.

9.1 Escalating a missed target

Where a response target in section 4 has passed without a substantive reply, escalate immediately — you do not need to wait for the update cadence. That is precisely the case the escalation path exists for, and it will be treated as such.

9.2 Commercial escalation

A dispute about a service credit, or about whether this agreement is being honoured, is escalated to Level 3 and then to the notice procedure in the Terms of Service, section 11. We will attempt to settle it in good faith for at least not yet confirmed: escalation period before either party commences proceedings, without preventing either party from seeking urgent relief.

9.3 Social escalation

A public post is a legitimate way to escalate, and you are not required to exhaust the route above first. It will be read. It will not, on its own, change the technical priority of a P1 — severity is set by impact, not by visibility — but escalating on a well-supported account of a missed target will be treated as information about our own performance that we would rather have internally. See also the Acceptable Use Policy, section 6.2, on criticism being welcome.

10.1 Everything else

• Client systems and configuration. Availability lost because of a client’s configuration, content, custom code, third-party integrations the client selected, or a change the client made directly, including to infrastructure we do not administer.
• Third-party platforms and providers. Cloud, hosting, domain registrar, certificate authority, payment gateway, app store, model provider, CDN, or any other external dependency, including its availability and its response to abuse or security notices it issues.
• Public networks. The internet between our provider and yours is not ours to make available.
• Force majeure. Events beyond our reasonable control, including natural disaster, war, civil unrest, epidemic or pandemic, government action, and widespread failure of an upstream provider. We publish targets, not promises that physics will cooperate.
• Denial-of-service and abuse traffic. Time lost to attacks we are mitigating is excluded, provided we are actively mitigating and have notified you.
• Beta, preview, staging, sandbox and trial environments. Included only where the statement of work names them expressly.
• Deprecated versions and unsupported configurations. Once a version or provider is out of its supported window, targets no longer apply and we will tell you when that begins.
• Work requested outside the statement of work. New features and scope changes are quoted, not supported on a target. See the Terms of Service, section 2.3.
• Cases we could not reasonably have detected. A defect with no observable symptom, in an environment with no monitoring, is not a missed target — but it is something we will help you find during active support.

This agreement is reviewed at least once every 12 months, and whenever a support process, monitoring configuration or third-party dependency changes materially. A review looks at actual performance against these targets, including the ones we missed, and at where the targets are wrong — targets that are consistently met with room to spare should be raised, and targets that are consistently missed should be fixed or formally withdrawn. A target nobody has looked at for a year is not a target, it is decoration.

Changes take effect for new engagements on notification, and for existing engagements on 30 days’ written notice. We will not weaken a target unilaterally mid-term without discussing it with you first. Changes to availability targets or credit bands are material changes and will always be discussed rather than announced.

Where a target in this document conflicts with a target in a signed statement of work, the statement of work wins, and we will fix whichever document is wrong.

• Provider: not yet confirmed: the registered legal entity name
• Support: hello@webnuvexa.com
• Tickets: not yet confirmed: ticket system URL
• Escalation L2: not yet confirmed: level 2 escalation contact
• Escalation L3: not yet confirmed: level 3 escalation contact
• Support window: not yet confirmed: support hours and time zone
• Out-of-hours: not yet confirmed: on-call availability

Raise a support request rather than a contractual dispute wherever the two are both possible — a conversation fixes far more incidents than a notice does. Where a contractual route is the right one, it is set out in the Terms of Service, section 11, and it will be handled without retaliation for raising it in good faith.