Reliability

Measured, not promised — what we publish about uptime.

We measure and publish uptime for every API and customer-facing surface. We don’t currently offer a contractual SLA with service credits — we’re focused on building reliability first, then commitments. The numbers below are real and updated hourly.

Last reviewed

01

Reliability commitment#

We publish what we measure. Every percentage on this page is computed at render from the same probe rows that feed the public status page — the 5-minute internal cron + the 60-second external Cloudflare Worker. There is no aspirational fudge factor.

A contractual SLA implies service credits, escalation paths, and a legal commitment we aren’t ready to make today. We’d rather earn the right to make it than make it and earn it back.

02

What “uptime” means at MantelMarketing#

We measure four customer-facing surfaces. Each definition below names the routes covered, the probe that decides “up,” and what we exclude.

Marketing site

marketing

Routes: mantelmarketing.com/* — public pages including /pricing, /examples, /faq

Definition of “up”: HTTP 2xx within 5 seconds from our external probe.

Excluded: Planned maintenance announced 7 days ahead. Third-party CDN incidents declared by Cloudflare.

App dashboard

dashboard

Routes: /app/* — the authenticated customer area

Definition of “up”: Both the database (Supabase) and authentication (Clerk) probes return ok within 5 seconds.

Excluded: Outages of an upstream we depend on (e.g. Clerk) when we are not the cause. We still report the downtime — we just don't claim it as our fault.

API

api

Routes: /api/* — programmatic surface (see /docs/api for the public spec)

Definition of “up”: Database probe returns ok within 5 seconds — every public POST hits Postgres.

Excluded: Routes behind admin / customer auth (those are scoped to dashboard).

Inbound email

inbound-email

Routes: inbound.mantelmarketing.com — receives customer replies (L3 inbound pipeline)

Definition of “up”: Resend probe returns ok within 5 seconds.

Excluded: Sender-side delays from your mail provider, greylisting, recipient-domain DNS issues outside our control.

/admin/* is internal-only and is not part of the customer-facing uptime measurement. Customer-site uptime (the marketing sites we host on your behalf) is measured per-project and visible to the project owner at /app/uptime.

03

Trailing 30 / 90 day uptime#

Per-surface uptime % computed from — snapshots in the last 30 days and — in the last 90. Each snapshot represents a 5-minute window.

Trailing uptime by surface
SurfaceTargetLast 30dLast 90d30d outage
Marketing sitemarketing99.95%———
App dashboarddashboard99.90%———
APIapi99.90%———
Inbound emailinbound-email99.50%———

The bar below each surface shows the trailing 30 days, one cell per UTC day. Cells with no snapshots render in grey — that’s “no data,” not “0%.”

Marketing site—
    App dashboard—
      API—
        Inbound email—
          04

          Aspirational targets — not contractual#

          These targets describe what we aim for. They are NOT a contractual commitment, and they do NOT carry service credits. We publish them so you can hold the measured numbers above against the bar we’ve set ourselves.

          marketingMarketing site
          Target99.95%
          Last 30d—
          —
          dashboardApp dashboard
          Target99.90%
          Last 30d—
          —
          apiAPI
          Target99.90%
          Last 30d—
          —
          inbound-emailInbound email
          Target99.50%
          Last 30d—
          —

          Customer-site uptime (the sites we build and host on your behalf) is measured separately per project and visible to the project owner at /app/uptime. We don’t aggregate it on this page because each customer’s expectations are their own.

          05

          Maintenance windows#

          We do not currently schedule maintenance windows. When we need a deploy that may briefly affect availability, we ship outside business hours (US Pacific) and announce on /status.

          06

          Incident communication#

          Active incidents are posted at /status. Subscribe to incident notifications via the form at the bottom of that page. Critical incidents page our on-call within 5 minutes — see /security for our incident-response posture.

          07

          Reporting an outage#

          If we miss what your monitoring caught, email security@mantelmarketing.com or post a note via /status with as much detail as you have — timestamp, route, error code, your monitoring tool’s URL.

          08

          What's not in scope today#

          Honest disclosure of what this page does not cover yet:

          • Service credits — we don't currently issue them. We may issue pro-rated refunds at our discretion when we cause an outage that breaches the disclaimers in our terms — see /terms.
          • A published RTO / RPO commitment to customers — internal targets exist (see /security for the disaster-recovery posture); we don't publish them externally yet because we want to measure them for at least four quarters before naming a number.
          • A third-party uptime monitoring partner (Pingdom, StatusCake, etc.). Today we run two probes: an external Cloudflare Worker (60s) and an in-app cron (5 min). External monitoring is a planned add.
          • Custom SLAs for enterprise tiers — flagged as future work; today every customer is on the same standard subscription.

          Page last reviewed May 4, 2026. Numbers refresh hourly from the health_snapshots table.