Service Level Agreement — Launchr

Version: 1.0 (August 2026)
Effective Date: 23 August 2026
Last Updated: 21 August 2026

1. Introduction

This Service Level Agreement (SLA) sets out the availability targets and support commitments that apply to the services Launchr Pty Ltd (ABN 46 696 518 206) provides to you. It describes what we promise, how we measure it, and what happens when we miss our targets.

This is not a SaaS subscription agreement. Most of what we sell is one-off fixed-price work — BUILD, FIX, and SITES are paid once, delivered once. RUN is the only recurring service. This agreement reflects that reality.

Who we are

Launchr Pty Ltd
ABN 46 696 518 206
Brisbane, Queensland, Australia
Governed by Queensland law

2. Scope — What this SLA covers

This SLA applies to these services:

What this SLA does not cover

• The code you write. We build it, you own it. The SLA covers our platform and service delivery, not the quality of your business decisions or whether your customers use it.
• Your own infrastructure choices. If you host elsewhere or integrate with third-party services, we cover Launchr only.
• Free review and pitch services. The initial board review and pitch are not covered by this SLA — they are provided in good faith.
• Third-party services (your own hosting or DNS if you host elsewhere, Stripe, third-party APIs your build uses).

3. Support Hours and Contact

Standard support (all clients)

Support is available Monday to Friday, 9:00 am to 5:00 pm Australian Eastern Standard Time (AEST), excluding Queensland public holidays.

• Email: [email protected]
• Expected response time: 2–4 business hours during support hours
• Outside support hours: Your request is queued and answered first thing the next business day

Emergency support outside business hours

If you are on a RUN plan and your live product is down, we monitor it. See §4 below.

If your engagement includes Premium Support — an optional add-on arranged by custom quote — the contact arrangements are set out in your quote. Premium Support includes:

• After-hours phone support for emergencies (24-hour incident notification)
• 1-hour response time commitment during the emergency window
• Incident escalation and priority handling

Without Premium Support, emergency contacts submitted after hours are acknowledged and triaged first thing the next business day.

4. Uptime Targets and Monitoring

RUN service uptime (the only recurring service)

We commit to 99.0% uptime each calendar month for your live product hosted on our platform.

What uptime means: Your live app is reachable and responds to HTTP requests from our external monitoring. Checks run automatically around the clock, at intervals of no more than 5 minutes.

What downtime means: The app is unreachable, or core functions (database, API) are unavailable for more than 5 minutes as detected by automated monitoring. Downtime does not include:

• Scheduled maintenance (announced 7 days in advance, 2 hours or less, typically Sunday 12:00–2:00 am AEST)
• Client-side errors (a bug in code you wrote, or a broken third-party integration)
• Third-party outages (Stripe, external APIs, or other third-party services your build depends on)
• DDoS or attack traffic we are actively defending against

Monitoring and status page

Weekly canary scanning: Every Monday 2:00 am AEST, we run an automated scan of all live builds in the RUN service. The canary:

• Tests each app's core flows (login, key transactions, critical endpoints)
• Checks configuration compliance (SSL certificates, DNS, database connectivity)
• Alerts our team to drift from specification
• Does not affect customer availability; it runs alongside your live traffic

Public status page: Real-time service status is published at https://status.launchr.bot. All monitoring and incident notifications go there first. You can:

• View current status and historical uptime
• Subscribe to notifications by email
• See active incidents and their resolution progress

If you are on RUN and an incident is in progress, check status.launchr.bot for real-time updates.

BUILD, FIX, SITES — delivery timeline targets

These are one-off services with fixed scope. The SLA target is delivery within the agreed timeframe (typically 5–15 business days depending on the tier):

If we miss the target delivery date by more than 5 business days and the delay is our fault (not pending client feedback or blocked dependencies), you are eligible for a refund of the full service fee. See §5.

5. Service Credits and Remedies

RUN service (recurring)

If we miss our 99.0% uptime target in a calendar month due to a failure of our platform (not third-party services, not your code, not scheduled maintenance), you are eligible for a service credit:

How it works:

1. We notify you via status.launchr.bot when an incident ends
2. We calculate uptime for the month on the last day of the month
3. If you are owed a credit, it is applied to your next invoice automatically
4. If you cancel before the credit is used, it expires

Your exclusive remedy: Service credits are your exclusive remedy for uptime misses. You cannot claim damages in addition, except for your rights under the Australian Consumer Law (see §7 below).

BUILD, FIX, SITES (one-off services)

If we miss our delivery target by more than 5 business days through our fault, you are eligible for a full refund of the service fee.

If we cannot deliver the service as promised (the build doesn't work, the site is broken, the scan finds nothing), you are refunded in full. This is a warranty against defects. It sits in addition to your rights under Australian Consumer Law — it does not replace them.

How it works:

1. Tell us in writing at any point before you accept and take delivery of the work (or, for delivery delays, as soon as the delay becomes apparent)
2. We have 5 business days to investigate and either fix the issue or confirm the refund
3. Refunds are processed to your original payment method within 10 business days
4. If the issue is on our side (broken platform, configuration error, missed scope), refund is approved
5. If the issue is on your side (you don't like the design, scope crept during work), we discuss and resolve in the build loop — refund is not automatic

6. What Downtime Does Not Include

We do not count toward downtime:

• Scheduled maintenance: We announce 7 days ahead. Typically every Sunday 12:00–2:00 am AEST, up to 2 hours.
• Your application bugs: If you write code that crashes or leaks memory, that is not our downtime.
• Third-party failures: Stripe errors, email-delivery failures, third-party APIs you integrate with — we monitor them and escalate, but we don't count them as our downtime.
• DDoS and active defense: If we are actively defending your app against a cyberattack, that traffic is not counted as a success. The app stays up; the SLA still applies. But we do not double-count defense traffic as SLA misses.
• Client-initiated changes: If you change DNS, revoke API keys, or change your Stripe account configuration, we cannot serve traffic — that is your downtime, not ours.
• Maintenance windows you authorized: If you ask us to take your app down for a critical update or migration, that is scheduled and exempt.

7. Compliance Drift Monitoring — the Weekly Canary

Every Monday at 2:00 am AEST, we run an automated canary across all RUN builds:

1. Functional test: Core user flows (login, create, read, update, delete, checkout if applicable) are tested automatically.
2. Configuration audit: We check SSL certificates, DNS resolution, database connectivity, and critical secrets are present.
3. Drift detection: We compare the live build against the spec you approved. If we find drift (config has changed without your say-so, or code has drifted), we flag it.
4. Your notification: If the canary finds issues, we email you within 4 business hours with details and next steps.

The canary is non-destructive and runs alongside your live traffic. It does not affect customer experience.

What if the canary finds drift?

• Low severity (e.g., a deprecated library, a non-critical config mismatch): We email you. No SLA hit, no automatic action.
• High severity (e.g., SSL cert has expired, database is unreachable, critical secret is missing): We escalate. During business hours, we call. Outside business hours, we notify via status.launchr.bot and start incident response.

If drift is due to our platform infrastructure failing (database unreachable due to our hardware, not your connection), it counts toward uptime SLA. If it is due to your configuration or a third-party service, it does not.

8. Planned Maintenance

When planned maintenance is needed, we schedule it for a Sunday between 12:00 am and 2:00 am AEST (typically 30 minutes, up to 2 hours in extreme cases). Most weeks there is none.

• Notice: 7 days' notice posted to status.launchr.bot
• Impact: Your live builds may be unreachable. Read-only traffic usually works; writes may fail.
• Frequency: As needed — always announced ahead, never unannounced
• SLA impact: Scheduled maintenance does not count as downtime

If we need emergency maintenance outside this window, we notify you ASAP via:

1. Email to the account contact
2. Notification posted to status.launchr.bot
3. SMS if Premium Support is active

Emergency maintenance outside normal windows is rare and does count as downtime for uptime percentage calculation — but we will refund credits if emergency maintenance is frequent (more than once per quarter).

9. Support Availability by Service

RUN (recurring, live product)

• Status page: 24/7 at https://status.launchr.bot
• Incident notification: Real-time via status page and email
• Support request: Monday–Friday 9 am–5 pm AEST, 2–4 hour response target
• Emergency escalation: Available if Premium Support is purchased (24-hour callback target)

Without Premium Support, emergencies outside business hours are triaged first thing the next business day.

BUILD, FIX, SITES (one-off services)

• Support request: Monday–Friday 9 am–5 pm AEST during the engagement
• Response target: 2 hours (urgent questions), 4 hours (general)
• Escalation: After 4 hours without response, email [email protected] with "URGENT" in the subject
• Emergency calls: Not provided in the standard tier (available via custom quote)

What counts as "urgent"?

• Your app is down and we broke it (you bought BUILD, it launched, now it is broken)
• A deployed FIX or SITES delivery is broken and we shipped it that way
• A security incident or data issue

What does not count as urgent:

• You want to change the scope of a build mid-delivery
• You want to dispute a refund decision
• You want to negotiate a price

10. Support During Build Engagement

While we are building, fixing, or delivering a site:

• Daily check-in: We email progress every 24 business hours unless you say otherwise
• Questions from you: We answer within 2 hours (or first thing next day if outside hours)
• Changes you request: Free revisions within scope. If scope grows, we discuss before the work starts.
• Blockers: If we are waiting on you (e.g., you to approve a design, or provide credentials), that time does not count against the delivery target

After delivery and you take the build, support moves to the terms that apply to your ongoing use (RUN, or the relevant product SLA).

11. Measurements and Reporting

Uptime calculation (RUN only)

Uptime % = (Total minutes in month − Downtime minutes) / Total minutes in month × 100

• Total minutes in a month = days in month × 24 × 60
• Downtime = sum of all incident durations >1 minute, excluding scheduled maintenance and third-party outages
• Rounding: To one decimal place

Example: August has 744 hours = 44,640 minutes. If downtime is 30 minutes, uptime = (44,640 − 30) / 44,640 = 99.93%.

Incident declaration

An incident is declared when:

1. Our monitoring detects a failure (HTTP 5xx, timeout, or connectivity loss for >5 minutes), and
2. The failure is in our infrastructure (not your code, not a third party), and
3. It affects at least 1 customer (not a canary-only failure)

We resolve when:

• The service returns to normal operation (successful HTTP responses, <5 second response time)
• and it remains stable for 5 consecutive minutes
• and we confirm customer traffic is flowing normally

Reporting

• Uptime reports: Available on demand; calculated monthly for billing purposes
• Status page: Real-time updates at https://status.launchr.bot
• Incident postmortems: Available on request within 10 business days of serious incidents (SLA miss >2 hours)

12. Limitations of This SLA

This SLA does not apply to:

• Failures caused by you: If your code is broken, or you configure something incorrectly, that is not our SLA failure.
• Failures caused by third parties: Stripe, email providers, other SaaS tools, or external APIs — we monitor and escalate but do not own their uptime.
• Service you do not pay for: Free reviews, consultations, and advice are provided in good faith but are not SLA-bound.
• Force majeure: War, natural disaster, government action, pandemics, or other events beyond our control. We will notify you and suspend SLA obligations.

Australian Consumer Law

This SLA does not exclude or limit your consumer guarantees under the Australian Consumer Law. If you are a consumer as defined by that law, our guarantee sits in addition to your statutory rights, not instead of them. You cannot be asked to waive those rights.

Those statutory rights include:

• Supply in due time and of acceptable quality
• Fit for purpose (if we know your intended use)
• Remedies if goods or services fail to meet those standards (repair, replacement, or refund)

This SLA defines how we implement those rights and what to expect from Launchr specifically.

13. Dispute Resolution and Complaints

Step 1: Contact us

If you believe we have missed an SLA target or obligation:

1. Email [email protected] with details (date, time, service, impact)
2. Title the email "SLA Claim" and include screenshots or error logs if possible
3. We respond within 2 business days

Step 2: Investigation

Within 5 business days, we:

• Examine our logs and monitoring data
• Determine whether the failure was our responsibility
• Offer remedies (service credit, refund, or explanation of why we don't owe one)

Step 3: Escalation

If you disagree with our decision:

1. Reply to our decision email with your objection
2. We escalate internally within 2 business days
3. A senior team member reviews and provides a final decision

Step 4: External dispute resolution

If we cannot agree:

• For consumers (Australian Consumer Law): The ACCC (https://www.accc.gov.au/) publishes guidance on your consumer rights, and you can pursue a consumer dispute through the Queensland Office of Fair Trading or QCAT.
• For all customers: You may pursue civil action under Queensland law (see §14).
• For all disputes: We agree to attempt mediation before litigation.

14. Governing Law and Jurisdiction

This SLA is governed by the laws of Queensland, Australia, and you agree to submit to the exclusive jurisdiction of Queensland courts.

Our details:

Launchr Pty Ltd
ABN 46 696 518 206
Brisbane, Queensland
Email: [email protected]

15. Changes to This SLA

We reserve the right to change this SLA with 30 days' notice. Changes are published on our website and emailed to all active customers. If you don't accept the changes, you can cancel (for RUN) or decline to use affected services (for one-off services).

Material changes that reduce your protections or increase our exclusions require your explicit agreement before taking effect.

16. Definitions

17. Contact and Support

Email: [email protected]
Status page: https://status.launchr.bot
Hours: Monday–Friday, 9 am–5 pm AEST

For emergencies on a RUN plan, check status.launchr.bot. If Premium Support is active, call the number in your contract.

Appendix A: Service Targets at a Glance

Document ID: launchr-sla-v1-august-2026
Approved for publication: 21 August 2026
For legal review: Use in conjunction with Terms of Service, Privacy Policy, Acceptable Use Policy, and Data Processing Agreement.