Add SLA feature page

[scout-relayprotocol]

Implements MAR-1404: Create SLA Product Marketing

What this changes

• Adds a new Service Level Agreements feature page covering Relay's availability, quote, and execution commitments.
• Explains eligibility and the enterprise qualification flow.
• Adds the SLA page to the Features navigation.

How I verified

• git diff-tree --check HEAD^
• Parsed docs.json and confirmed the features/slas navigation entry.
• Confirmed required page frontmatter and status-page link.

Open questions

• None.

---

🤖 Opened by Scout (autonomous). Ready for human review.
Linear: https://linear.app/relayprotocol/issue/MAR-1404/create-sla-product-marketing

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	Jul 28, 2026, 2:03 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[github-actions]

Claude finished @pedromcunha's task in 3m 54s —— View job

---

Code review: PR #380 — Add SLA feature page

• Gather context (diff, AGENTS.md style guide, exemplar feature pages)
• Check features/slas.mdx against §3.1 Feature guide profile + §2 global rules
• Verify docs.json nav wiring and link/terminology conventions
• Post review findings

Reviewed features/slas.mdx (new, 55 lines) and the docs.json nav entry against AGENTS.md. The nav wiring is correct and the frontmatter, paragraph length, horizontal-rule usage, and emphasis conventions all comply. The findings below are mostly about placement, undefined terms, and claims I can't verify — nothing is a hard style-guide violation except the missing links.

---

1. Placement: this reads like a solutions/ page, not a feature guide

To be precise about the guide: §3.1 says only the intro paragraph is required and that automation "should validate the shape of sections that are present, not flag missing ones." So the absence of ## Requirements / ## How to use it? / ## Caveats is not a rule violation. The fit question is still worth settling before merge:

• §3.1 describes feature guides as "practical, task-oriented," answering "what is it, who needs it, how do you wire it up, what goes wrong." There is nothing to wire up here — an SLA is a commercial term, not an integration surface. Every sibling in features/ documents a callable capability (app-fees, fast-fill, fee-sponsorship, gasless-swaps, price-stabilization).
• The actual shape used — ## How it works plus benefit lead-ins plus audience segmentation — is the §3.2 use-case profile, and the audience-segment framing already has a home: solutions/payment-service-providers.mdx, solutions/wallets-and-wallet-providers.mdx, solutions/dex-and-dex-aggregators.mdx map almost 1:1 onto the four bullets on lines 50–53.

§4.1 makes this explicitly a human call ("make a draft, flag surfaces that might need a companion update, let the PR author decide") — so flagging rather than asserting. If it stays in features/, consider aligning the headings to the §3.1 profile. Fix this →

2. status.relay.link is unverified, and two claims depend on it

features/slas.mdx:29 links to https://status.relay.link, the only reference to a status page anywhere in the repo. I could not verify it resolves — this run has no network access. Please confirm before merge that the page exists and actually publishes per-route rolling 30-day SLA/SLO performance, because two assertions rest entirely on it: line 21 ("published alongside SLA performance") and line 40 ("Check published rolling 30-day performance instead of waiting for a renewal review"). If the status page publishes only current uptime, both claims overstate what a reader can do today.

3. "Tier-1 routes" and "SLOs" are new, undefined, and load-bearing

grep across all .mdx shows neither term appears anywhere else in the docs. "Tier-1" scopes every commitment on the page (slas.mdx:14, slas.mdx:55) but is never defined, so a reader can't tell whether their corridors qualify — which is the first question this page should answer. Either define it inline or link to a page listing covered routes. Both terms also belong in the §5 terminology list if they ship. Fix this →

4. The SLA page's numbers are vaguer and weaker than the marketing pages'

§2.4 asks for concrete numbers when available, and they already exist elsewhere in this repo:

This PR	Existing page
slas.mdx:18 — "quote latency at p50, p95, and p99 for each route category" (no values)	solutions/wallets-and-wallet-providers.mdx:20 — "p50 fill time … less than 3 seconds"
slas.mdx:19 — "success-rate commitments up to 99.9%"	solutions/payment-service-providers.mdx:58 — "99.9%+ fill success with sub-3-second settlement"

As written, the page that is supposed to harden these numbers into commitments states them more weakly than the pages that market them. "Up to 99.9%" also reads as a ceiling rather than a floor, which is the opposite of how an SLA target works. Worth reconciling so the two don't contradict. Fix this →

5. Zero internal links (§2.6)

§2.6: "When introducing a concept that has its own page, link on first mention." The page names covered chains, quotes, fills, deposit-through-settlement, and four audience segments — and links to nothing in-repo. Its only two links are the unverified status page and a mailto. Concrete candidates: /resources/supported-chains for covered chains, /features/fast-fill for fill speed, and the /solutions/* pages for the audience bullets on lines 50–52. Fix this →

6. Three existing pages already talk about SLAs and none link here

§4.1 asks a draft to flag companion surfaces. These are them — each carries a **SLAs & Customer Support** benefit block that is now the reader's first mention of a concept with a dedicated page:

• solutions/multichain-apps.mdx:22
• solutions/wallets-and-wallet-providers.mdx:22
• solutions/chains.mdx:18

Also worth a look: solutions/payment-service-providers.mdx:58 and solutions/commerce-and-payments.mdx:79 make reliability claims that this page now formalizes. Fix this →

7. "four metric families" but five metrics listed

slas.mdx:14 says four; the list at lines 16–19 names five, because line 19 bundles fill latency and fill success into one bullet. Split the bullet and say five, or drop the count. Fix this →

---

Minor

Filename. features/slas.mdx is the only acronym filename in the folder — every sibling spells words out (fast-fill, price-stabilization, gasless-execution). service-level-agreements.mdx would match both the folder convention and the title, and this URL is the kind of thing that gets pasted into a procurement doc. Cheaper to change now than after indexing. Fix this →

Contact address. mailto:support@relay.link (line 55) is consistent with existing practice (security/bounties.mdx:174, references/api/api_resources/supported-chains.mdx:22), so no style issue. But this page routes enterprise agreement and procurement inquiries there — if a sales/BD alias exists, that's probably the better target.

Contractual language. Lines 6, 18, and 19 use binding phrasing ("contractual performance commitments," "Relay commits to") with specific numeric targets. Worth a legal/BD read before publish, since a docs page can set expectations independent of what any given enterprise agreement actually says. Outside what I can assess from the repo.

What's correct

• Frontmatter matches §2.1; no # in body; ##/### depth respected (§2.2).
• Paragraphs within the 2–3 sentence cap (§2.10); no italics; bold used per the established lead-in pattern (§2.9).
• Horizontal rules separating major sections, which §2.5 specifies for feature guides.
• No callouts, so the 15-line cap and nesting rules aren't at issue.
• docs.json addition is well-formed and correctly placed in the Features group.

I did not make any changes — this was a review only. Note that findings 2 and the contractual-language item need product/legal input rather than an edit.
· Branch