Service Level Agreement (SLA)

Last updated: June 12, 2026

This Service Level Agreement ("SLA") describes the availability commitment DeployMill makes for the DeployMill service, and the service credits available when we miss it. It forms part of the Terms of Service for the plans it applies to.

1. Scope (what this SLA covers)

This SLA covers the DeployMill control plane:

• the MCP API (/mcp), the tool surface your connected AI agent uses to

  deploy and operate apps;

• the REST API (/api/v1) and the authentication endpoints; and
• the dashboard (sign-in, account, and app-management pages).

It does not guarantee the uptime of any individual application you deploy through DeployMill. Your app's availability depends on your own code, its resource configuration, and the backends you've chosen for it (database, object storage, and so on). DeployMill operates the underlying compute and ingress with care (health-gated deploys, automatic rollback, per-organization isolation) but a crashing app, an exhausted database, or a misconfigured domain is not control-plane Downtime. Put simply: if the control plane is up, your agent can always deploy, roll back, inspect logs, and manage your apps. What your app does once deployed is yours.

Plans

2. Definitions

• "Monthly Uptime Percentage" means, for a calendar month: 100% minus the

  percentage of minutes in the month during which the control plane was in Downtime. Months are measured in UTC.

• "Downtime" means a period of at least one full minute during which the

  control plane (the MCP API or the dashboard) returns server-error responses or fails to respond to well-formed requests, as measured by DeployMill's monitoring, excluding the exclusions in Section 5.

• "Scheduled Maintenance" means maintenance announced at least 48 hours in

  advance through the status page or email, performed within the announced window.

• "Service Credit" means a credit, calculated as a percentage of the

  Customer's monthly fee for the affected month, applied against future invoices (or, for prepaid annual plans, against the monthly-equivalent fee).

• "Exclusions" means the events listed in Section 5, which do not count as

  Downtime.

3. Uptime commitment

DeployMill commits to a Monthly Uptime Percentage of at least 99.9% for the control plane on covered plans (≈ 43.8 minutes of allowable Downtime per month).

Service credits

If the Monthly Uptime Percentage for a calendar month falls below the commitment, eligible customers may claim a Service Credit:

Service Credits in any calendar month will not exceed 50% of that month's fee. Credits have no cash value, are not refundable, do not apply to free-tier usage, and expire if unused when the Agreement terminates (except where the termination is by the Customer for DeployMill's uncured material breach).

4. What counts as Downtime

Downtime is measured against the control plane's externally observable behavior: the MCP endpoint, the REST API, and the dashboard failing to serve well-formed, authenticated requests. Examples that do count:

• The MCP API is unreachable or consistently returning 5xx errors, so agents

  cannot deploy, roll back, or read logs.

• The dashboard or sign-in flow is down platform-wide.
• A platform-wide ingress failure caused by DeployMill's own control plane

  (as opposed to an individual app's configuration).

Examples that do not count: a single deploy failing its health gate (the guardrail working as designed), an individual app crash-looping, slow builds, or degraded performance that still serves requests successfully.

5. Exclusions

The following do not count as Downtime and are not eligible for Service Credits:

• Scheduled Maintenance performed within an announced window (Section 7).
• Customer-caused issues, including the Customer's own application code,

  resource exhaustion within the Customer's apps, misconfiguration (DNS, domains, environment variables, Dockerfiles), and actions taken by the Customer's connected AI agent. Agent actions are the Customer's instructions: if an authorized agent deletes an app, exhausts a quota, or deploys a broken build, that is not control-plane Downtime. (DeployMill's guardrails (preview isolation, health-gated deploys with auto-rollback, dry-runnable plans, and the audit trail) exist to bound exactly this risk, but they do not convert agent-caused outcomes into SLA events.)

• **Third-party and subprocessor outages outside DeployMill's reasonable

  control**, for example, an outage at GitHub (source), Cloudflare R2 (object storage), or an optional managed-database backend such as Neon or Supabase. DeployMill's architecture is deliberately provider-neutral, and the default stack keeps the most critical paths (compute, internal Postgres, ingress) on infrastructure DeployMill operates itself (which narrows this exclusion in practice) but where a third-party backend the Customer has selected is down, that outage may be excluded. The current backends are listed at Subprocessors.

• Force majeure, events beyond DeployMill's reasonable control,

  including internet backbone or regional network failures, denial-of-service attacks despite reasonable mitigation, natural disasters, and acts of government.

• Suspension or termination of the Customer's account or apps in

  accordance with the Terms of Service or the acceptable-use policy.

• Beta, preview, or experimental features, and any feature documented as

  best-effort.

• Downtime during a period when the Customer is in material breach of the

  Agreement, including non-payment.

6. Claiming a service credit

1. Email [email protected] with the subject line "SLA credit claim"

   within 30 days of the end of the calendar month in which the Downtime occurred.

2. Include: your organization name, the dates and times (with timezone) of

   the Downtime you observed, and any supporting detail (error responses, request IDs, affected endpoints).

3. DeployMill will validate the claim against its monitoring data and

   respond within 10 business days. If the claim is confirmed, the Service Credit will be applied to a future invoice.

Claims submitted after the 30-day window are ineligible. Service Credits are the sole and exclusive remedy for any failure by DeployMill to meet the uptime commitment in this SLA. They do not limit either party's rights under the Terms of Service for matters other than availability.

7. Maintenance windows and status communication

• Scheduled Maintenance is announced at least 48 hours in advance on

  the DeployMill status page and, for enterprise customers, by email to the nominated operations contact. Where possible, maintenance is performed without interruption (the platform's health-gated rolling updates apply to DeployMill's own deploys too). Windows are scheduled for low-traffic periods.

• Emergency maintenance (for example, an urgent security patch) may be

  performed with shorter or no notice. DeployMill will post to the status page as soon as practicable. Emergency maintenance that causes unavailability counts as Downtime unless it falls under an exclusion in Section 5.

• Incidents are tracked on the status page from detection through

  resolution. For security incidents involving personal data, breach notification follows the Data Processing Agreement. Platform security practices are described at Trust & Security.

8. Changes to this SLA

DeployMill may update this SLA from time to time. Material reductions to the uptime commitment or the credit schedule take effect no earlier than 30 days after notice (via the status page, the dashboard, or email) and apply prospectively, never to a month already in progress. The "Last updated" date at the top reflects the latest revision. For enterprise customers with a negotiated SLA in an order form, the negotiated terms control over this page.

9. Contact

• Service credit claims and incident reports: [email protected]
• Contract questions, including negotiated enterprise SLAs:

  [email protected]

• Data protection: [email protected] (see the

  Data Processing Agreement)