P1 Incident SLA

1. Coverage

This SLA applies to Tier 3 (Run the whole digital side for me) from the first day of the engagement. Tier 1 (Keep my site running) and Tier 2 (Help customers find me and stop losing leads) are not covered by this SLA; those tiers have business-hours priority response only. Watchtower is a monitoring-only service: it alerts you to a problem, but it carries no human response commitment and is not covered by the 60-minute money-back response acknowledgement below, which applies to Tier 3 only. This SLA applies to the primary production domain we are engaged to manage. Add-ons (AI Visibility, Email Health and Deliverability, hosted email, and similar) are covered by their own scope.

2. What counts as a P1 incident

A P1 is one of:

• Site is down. The primary domain returns a 5xx error or no response for 5+ consecutive minutes from our Australian-based monitoring.
• Customer money path is broken. The checkout, booking, payment, or quote-request action used by paying customers is failing (form submission errors, payment processor rejection, cart not adding, etc.).
• Email reaches spam at scale. A demonstrable deliverability incident: legitimate mail from your domain being rejected, bounced, or marked spam by a major inbox provider (Gmail, Outlook, Apple Mail).
• Security incident. Your site is defaced, hijacked, redirected, or your SSL certificate is publicly broken (browser warning showing).

A P1 is NOT:

• Slow page load. (Tracked separately under monthly Lighthouse trend.)
• Cosmetic issue, layout change, or content correction.
• Routine content/copy update request.
• Feature request or new functionality.
• Degraded third-party service the platform vendor has acknowledged (a hosting, DNS, or payment provider outage shown on their own status page, etc.).
• An issue you have introduced and want us to roll back (we'll do it fast, but it's not a P1 against us).

If we disagree on whether something is P1, we err on your side once. After that, the definition above applies.

3. Response time targets

Respond means: we acknowledge in writing (email, SMS, or message in our shared channel) that we have seen the incident, confirm what we are doing, and give an initial estimate. It does NOT mean fully resolved. Some P1s take minutes to fix; some take longer. The promise is on the response, not the resolution.

Response time depends on the P1 category:

Why the tiering: a site-down incident is detected automatically by our monitoring within 60 seconds (our custom agentic monitoring and alerting centre) and pushes straight to a phone configured to override do-not-disturb. The infrastructure to honour 60-minute-any-time is fully automated, so we can promise it on every category that monitoring catches end-to-end. The other three categories often require human verification of the incident (e.g. a customer report that "the booking form is broken" needs us to look) so the overnight window is realistic, not optimistic. All four categories receive the same 60-minute response during waking hours.

The clock starts when:

• Our monitoring detects the incident (our custom agentic monitoring and alerting centre), OR
• You notify us via the agreed contact channel,

whichever is earlier. The clock stops when we have sent the written acknowledgement.

4. The credit

If we miss the response target on a P1 (per §3):

• Your next monthly invoice for the affected tier is waived in full. One free month.
• You do not need to claim it. We monitor our own response times and apply the credit automatically on the next invoice, with a one-line note explaining why.
• Maximum one credit per calendar month, regardless of how many P1s occurred. We are not in the business of farming our own SLA breaches.
• Credits apply to the recurring Tier 3 fee only. Add-ons, hosted email, Foundation Setup, and other one-off work are not credited under this SLA.
• Credits are not cash refundable. They reduce a future invoice.

5. Exclusions

The response clock does NOT run when the incident is caused by:

• A platform vendor outage. If a core upstream provider (hosting, DNS, payments, or email) is having an incident their own status page has acknowledged, we follow their resolution. We will keep you informed; we will not refund a month for an outage that was theirs.
• Customer-side action. You (or someone with access on your side) made a change that broke the site: CMS edit, DNS change, plugin install, content upload, payment processor reconfiguration.
• Loss of access we need. You have revoked, expired, or not granted the access we need to operate the system.
• Force majeure. Natural disaster, war, large-scale internet outage, government action.
• Scheduled maintenance. Any work we have given you 24+ hours written notice of.
• A beta or experimental feature explicitly flagged as such in writing.

6. What this SLA does not cover

This is a response-time SLA, not an uptime guarantee or a fix-time guarantee. We do not promise:

• A specific uptime percentage. (Our actual uptime tracks at 99.9%+ on the infrastructure we run, but we don't write a number into a contract we cannot personally guarantee against a platform vendor's behaviour.)
• A specific time to fix. Some P1s are 5 minutes; some are 5 hours. The promise is on the response window (per §3) and you know exactly what's happening from that point on.
• Compensation for indirect or consequential loss (lost revenue, lost opportunity, reputational harm). The next-month-free credit is the sole remedy under this SLA. This is consistent with the limitations section of the general Terms of Service.

7. How we deliver this

For transparency, our response capability is:

• Continuous synthetic monitoring via our custom agentic monitoring and alerting centre, running from our Australian-based data centre, with HTTP, SSL and security-header checks every 60 seconds on every monitored domain.
• Nightly deep checks via our custom verification sweep covering DNS, AI visibility, deliverability state, and deploy state.
• Push notification to the operator's mobile for every critical monitoring alert (configured to bypass do-not-disturb).
• Discord ops channel mirroring every alert with full context.
• Shared incident log retained for 90 days, available to you on request.

We don't promise this SLA because we hope to be lucky. We promise it because the infrastructure to honour it is already in place and tested.

8. Changes to this SLA

We may revise this SLA with 30 days written notice. If a change reduces the level of service materially, you may cancel the SLA (or the whole engagement) within that window with no further obligation.

9. Effective date

This SLA is effective from the first day of your active paid tier and remains in force until the engagement ends.