docs(landing): catch the changelog up to 2026-11-07

apps/landing/messages/en.json

@@ -452,7 +452,8 @@
 	"faq_home_agents_a": "Yes. Maple runs an MCP (Model Context Protocol) server, so compatible AI agents can list services, search traces, find errors, and propose fixes directly against your telemetry.",
 
 	"hero_announce_badge": "New",
-	"hero_announce_text": "Maple Local: one binary, no account.",
+	"hero_announce_text": "On-call in Maple: schedules, escalation and silences.",
+	"hero_announce_href": "/changelog/2026-11-07-on-call",
 
 	"signals_eyebrow": "01 · Signals",
 	"signals_trace_title": "Read the trace.",

apps/landing/messages/ja.json

@@ -441,7 +441,8 @@
 	"faq_home_agents_a": "はい。MapleはMCP（Model Context Protocol）サーバーを備えています。対応するAIエージェントは、サービス一覧の取得、トレース検索、エラーの特定、修正案の提示を、テレメトリに対して直接実行できます。",
 
 	"hero_announce_badge": "\u65b0\u7740",
-	"hero_announce_text": "Maple Local：ひとつのバイナリ、アカウント不要。",
+	"hero_announce_text": "Maple でオンコール：スケジュール、エスカレーション、サイレンス。",
+	"hero_announce_href": "/changelog/2026-11-07-on-call",
 
 	"signals_eyebrow": "01 · シグナル",
 	"signals_trace_title": "\u30c8\u30ec\u30fc\u30b9\u3092\u8aad\u3080\u3002",

apps/landing/messages/ko.json

@@ -441,7 +441,8 @@
 	"faq_home_agents_a": "네. Maple은 MCP(Model Context Protocol) 서버를 실행합니다. 호환되는 AI 에이전트는 서비스 목록 조회, 트레이스 검색, 오류 탐색, 수정 제안을 텔레메트리에 직접 수행할 수 있습니다.",
 
 	"hero_announce_badge": "\uc2e0\uaddc",
-	"hero_announce_text": "Maple Local: 바이너리 하나, 계정 불필요.",
+	"hero_announce_text": "Maple 온콜: 스케줄, 에스컬레이션, 사일런스.",
+	"hero_announce_href": "/changelog/2026-11-07-on-call",
 
 	"signals_eyebrow": "01 · 시그널",
 	"signals_trace_title": "\ud2b8\ub808\uc774\uc2a4\ub97c \uc77d\uc73c\uc138\uc694.",

apps/landing/src/components/home/HomeHero.astro

@@ -18,19 +18,19 @@ import { DATA_POINTS_INGESTED, formatDataPoints } from "../../lib/ingest-stats";
 import { getGitHubStars, formatStars } from "../../lib/github-stars";
 
 const stars = await getGitHubStars();
-const locale = Astro.currentLocale ?? "en";
-const localPath = locale === "en" ? "/local" : `/${locale}/local`;
+// The changelog is English only, so the link is the same in every locale.
+const announceHref = m.hero_announce_href();
 ---
 
 <section class="monument-hero" aria-labelledby="home-title">
     <div class="monument-hero__field shell">
         <a
-            href={localPath}
+            href={announceHref}
             class="monument-announce"
             data-track="cta_click"
             data-track-location="hero_announce"
             data-track-label={m.hero_announce_text()}
-            data-track-destination={localPath}
+            data-track-destination={announceHref}
         >
             <span class="monument-announce__badge">{m.hero_announce_badge()}</span>
             <span class="monument-announce__text">{m.hero_announce_text()}</span>

apps/landing/src/content/changelog/2026-10-19-google-cloud.md

@@ -0,0 +1,26 @@
+---
+title: "Connect Google Cloud"
+description: "Bring Cloud Logging, Cloud Monitoring metrics and your Google Cloud resources into Maple, set up by script, console steps or Terraform."
+date: 2026-10-19
+category: integrations
+authors: [jeremyfunk, makisuo]
+---
+
+You can now connect a Google Cloud **organization, folder or project** to Maple. Each connection
+collects what you choose:
+
+- **Log forwarding.** Cloud Logging entries arrive in **Logs** under the service that wrote them.
+- **Metrics and resources.** Metrics for Cloud Run, Cloud Functions, GKE, Compute Engine, Cloud
+  SQL, Pub/Sub and HTTP(S) load balancers every 5 minutes, and the resources behind them every
+  hour. They are named `gcp.*` and work in dashboards and alert rules.
+
+**Infrastructure → Google Cloud** shows a health band across every workload (saturated, elevated,
+erroring), a table per service type, and a page per workload with its charts. The workloads also
+appear on the Infrastructure overview and the service map, and a dashboard template gets you a
+starting point.
+
+Pick how to set it up in the connect dialog: a Cloud Shell script, console steps with your
+connection's values ready to copy, or a Terraform or Alchemy file. The IaC option also comes as a
+prompt you can hand to a coding agent.
+
+Get started with the [Google Cloud guide](/docs/integrations/gcp).

apps/landing/src/content/changelog/2026-10-23-aws-cloudwatch.md

@@ -0,0 +1,24 @@
+---
+title: "Connect AWS and stream CloudWatch metrics"
+description: "Connect an AWS account with a read-only role and no stored secret, stream CloudWatch metrics, and see every resource under Infrastructure → AWS."
+date: 2026-10-23
+category: integrations
+authors: [makisuo]
+---
+
+You can now connect an **AWS account** to Maple. The setup creates a read-only IAM role in your
+account, deployed as a CloudFormation stack from CloudShell, in the console, or with Terraform.
+Maple assumes it with short-lived tokens it signs for your connection, so there is no access key
+to create, store or rotate.
+
+A connection can also **stream CloudWatch metrics** to Maple. Pick the regions and the services
+(ECS, Container Insights, ALB, NLB, RDS, Lambda, SQS, EC2, DynamoDB, API Gateway) and AWS pushes
+the metrics as they are published. Maple reads nothing back from the account.
+
+Once metrics arrive, **Infrastructure → AWS** lists each resource by kind: ECS services, EC2
+instances, load balancers, RDS, Lambda and SQS. A health band calls out what is hot, erroring,
+throttled, backed up, or idle and still billed, and filters the table to it. Each resource has a
+page with its metrics, a link to the AWS console and, for ECS services and Lambda functions, the
+traced service it runs as with its calls, errors and p95.
+
+Get started with the [AWS guide](/docs/integrations/aws).

apps/landing/src/content/changelog/2026-10-24-service-api-tab.md

@@ -0,0 +1,21 @@
+---
+title: "A rebuilt API tab on service pages"
+description: "See what an HTTP service rejects and why, what is slow, who calls it and how big the requests are."
+date: 2026-10-24
+category: services
+authors: [makisuo]
+---
+
+The **API** tab on a service page now answers what operators of an HTTP service ask first.
+
+- **A KPI strip**: requests per second, the 4xx share with its leading status code ("mostly 402"),
+  the 5xx share, p95 against the previous window of the same length, and request bytes per second
+  with the average body size. Each has a sparkline.
+- **Responses by status**: 2xx, 4xx and 5xx stacked over the window, with deploy markers.
+- **Non-2xx responses**: each status code with its count, share, most common error type and the
+  routes that returned it.
+- **An endpoint table** with filters for routes rejecting more than 5% of requests or slower than
+  100 ms at p95.
+- **An endpoint drawer**: click a route to see its status codes, latency distribution, top
+  clients, request body sizes and slowest requests, each linking to its trace. The URL keeps the
+  open endpoint, so you can share it.

apps/landing/src/content/changelog/2026-10-25-onboarding.md

@@ -0,0 +1,24 @@
+---
+title: "A new onboarding, and one connect flow for every source"
+description: "Onboarding asks what you run, connects it in place and ends on your own first data. Every source now connects through the same four steps."
+date: 2026-10-25
+category: platform
+authors: [makisuo]
+---
+
+Setting up a new organization is shorter and ends somewhere useful:
+
+1. **Plan.** Choose a plan, or skip it if your organization already has one.
+2. **Stack.** Pick your languages and where they run. Every language we document is listed, with
+   search. The page shows which parts of Maple those picks fill in.
+3. **Connect.** Set up what you picked. Each provider opens in a drawer, so you never lose your
+   place.
+4. **Team.** Invite people and bring in GitHub, Slack and your editor.
+5. **You're live.** See whether data is flowing, and start from your own data: the service map,
+   your slowest service and your errors from the last 24 hours. Anything you picked but haven't
+   connected yet is listed with its setup link.
+
+Adding a source later works the same way everywhere. **Sources → New** walks every integration
+through **Source, Connect, Choose data, Go live**. A status line says what Maple is waiting for or
+what it found, so there is no separate test button, and the side rail says what Maple reads before
+you grant it.

apps/landing/src/content/changelog/2026-10-26-uptime-monitoring.md

@@ -0,0 +1,28 @@
+---
+title: "Uptime monitoring"
+description: "Hosted HTTP, TCP, DNS and heartbeat checks that open incidents through your alert routing and link each failed check to its trace."
+date: 2026-10-26
+category: alerts
+authors: [makisuo]
+---
+
+Maple now runs **uptime checks** for you. Add a monitor from **Alerts → Uptime**, or pick
+**Uptime check** from **New rule**:
+
+- **HTTP**: status code, response time, body text, JSON path and header assertions.
+- **TCP**: the port accepts a connection.
+- **DNS**: the name resolves, optionally to the record you expect.
+- **Heartbeat**: your cron job or worker pings a URL on an interval or a cron schedule, and Maple
+  alerts when a ping is late or reports a failure.
+
+Checks run every 30 seconds to every hour. A monitor goes down after 1 to 10 failed checks in a
+row (2 by default) and comes back up on the first success. A down monitor opens an incident
+through the same routing as your alert rules, and the notification reads "checkout-api is down"
+with the check's error.
+
+Each HTTP check sends a `traceparent` header, so a failed check links to the trace your service
+recorded for it. The monitor page charts response time split into DNS, connect, TLS, time to
+first byte and transfer, so you can see which phase got slow. Link a monitor to a service and it
+shows on the service page, and counts toward that service's health.
+
+Read more on the [uptime monitoring page](/features/uptime-monitoring).

apps/landing/src/content/changelog/2026-10-28-ingest-rules.md

@@ -0,0 +1,24 @@
+---
+title: "Ingest rules: drop and redact data before it is stored"
+description: "Drop noisy logs, spans and metrics, or redact personal data and secrets, before Maple stores or bills them."
+date: 2026-10-28
+category: platform
+authors: [makisuo]
+---
+
+You can now write **ingest rules** that run on your telemetry as it arrives, before it is stored
+or counted toward your bill.
+
+- **Drop** logs, spans or metrics you don't need: health checks, debug logs from one service, a
+  chatty metric. You can drop all of them or keep a percentage.
+- **Redact** values in place, such as email addresses, tokens or card numbers in log bodies and
+  attributes.
+
+Find them under **Settings → Ingestion → Ingest rules**. The editor reads as a sentence (when,
+where, then) and has a **live preview**: it runs the rule against your 100 newest logs or spans
+from the last hour and shows what would be dropped and each value before and after redaction.
+The empty state offers templates to start from.
+
+Each rule shows its hits over the last 24 hours. **Billing & usage** shows how much data rules
+dropped in the current cycle, which is not billed. Rules are also available through the
+`/v2/ingest_rules` API.

apps/landing/src/content/changelog/2026-10-28-terraform-provider.md

@@ -0,0 +1,23 @@
+---
+title: "A Terraform provider for Maple"
+description: "Manage dashboards, alert rules, destinations, uptime monitors, scrape targets and API keys in Terraform."
+date: 2026-10-28
+category: api
+authors: [makisuo]
+---
+
+Maple now has a **Terraform provider**, `mapletechlabs/maple`. Declare your Maple configuration
+next to the infrastructure it watches, and review every change in a plan first:
+
+- `maple_dashboard`
+- `maple_alert_rule` and `maple_alert_destination`
+- `maple_uptime_monitor`
+- `maple_scrape_target`
+- `maple_api_key`, plus a `maple_ingest_keys` data source
+
+Existing resources can be imported, so you can bring what you built in the dashboard under Terraform
+without recreating it. The provider uses the public v2 API with an API key from
+**Settings → Keys**.
+
+Get started with the [Terraform guide](/docs/iac/terraform) and the
+[resource reference](/docs/iac/terraform-resources).

apps/landing/src/content/changelog/2026-10-30-otlp-grpc.md

@@ -0,0 +1,22 @@
+---
+title: "Send telemetry over OTLP/gRPC"
+description: "The ingest endpoint now accepts OTLP over gRPC as well as HTTP, so exporters that default to gRPC work without a protocol change."
+date: 2026-10-30
+category: platform
+authors: [makisuo]
+---
+
+Maple's ingest endpoint now accepts **OTLP over gRPC**, on the same host and port as OTLP over
+HTTP. Java, .NET, Python and the OpenTelemetry Collector often default to gRPC, and they can now
+send traces, logs and metrics to Maple as they are configured:
+
+```bash
+export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.maple.dev"   # https://ingest.eu.maple.dev for EU organizations
+export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer YOUR_INGEST_KEY"
+export OTEL_EXPORTER_OTLP_PROTOCOL="grpc"
+```
+
+gzip compression, request limits and ingest keys work the same as over HTTP. Errors come back as
+gRPC status codes, and the ones worth retrying are `UNAVAILABLE`, which exporters already retry.
+
+See the [Ingest API reference](/docs/reference/ingest#grpc).

apps/landing/src/content/changelog/2026-11-01-mcp-servers.md

@@ -0,0 +1,28 @@
+---
+title: "See how agents use your MCP server"
+description: "A new MCP servers page shows the tools agents call, the clients calling them, why calls fail, and each session and user, from the spans your server already sends."
+date: 2026-11-01
+category: ai
+authors: [makisuo]
+---
+
+If you run an **MCP server**, **Explore → MCP servers** now shows how agents use it. Maple reads
+the spans your server already emits under the OpenTelemetry MCP conventions. There is no extra SDK
+or second call to make.
+
+- **The list** has every service that answers MCP tool calls, with calls, failure rate, p95,
+  tool count, top client and a volume sparkline.
+- **A server's page** charts calls, failures, latency and clients, and breaks them down by tool,
+  client (Claude, Cursor and so on), failure kind and MCP method.
+- **A tool's page** groups its errors by type and message, and lists the slowest, failed and
+  recent calls, each linking to its trace.
+- **Sessions** group a server's requests by MCP session, in order, linked to the agent session
+  that made them and to the user behind it.
+
+A server that doesn't send what a view needs gets a checklist of the attributes to add, not an
+empty table.
+
+Connecting your own agent to Maple is also quicker: the **Connect** panel in the top bar has a
+copy-paste command for Claude Code and one-click install links for Cursor and VS Code.
+
+Read more in [MCP servers](/docs/mcp-servers/overview).

apps/landing/src/content/changelog/2026-11-03-error-grouping.md

@@ -0,0 +1,23 @@
+---
+title: "Merge duplicate issues and set error grouping yourself"
+description: "Merge error issues that are the same bug, split them back out, and name a grouping key in code when the automatic grouping gets it wrong."
+date: 2026-11-03
+category: errors
+authors: [makisuo]
+---
+
+Three changes to how errors become issues:
+
+- **Merge issues.** Select issues on the **Errors** page and choose **Merge**, then pick the one
+  to keep. Its count and builds include the others, and their future occurrences land on it. A
+  merged issue's page links to where it went and has **Unmerge**, which hands back exactly the
+  occurrences it brought. Merging is also available from the API and MCP.
+- **Set the grouping in code.** Put a `maple.fingerprint` attribute on an error span or its
+  exception event, and every error in that service with the same value becomes one issue,
+  whatever its stack or message. Use a fixed name for the failure, never a per-request value.
+- **Grouping by your own code.** When a stack has frames from your application, frames from
+  dependencies and the runtime no longer affect the grouping. An error thrown inside a library now
+  groups by the code of yours that called it. Existing issues carried over to the new grouping
+  with their state, history and counts.
+
+See [How errors are grouped](/docs/errors/overview#how-errors-are-grouped).

apps/landing/src/content/changelog/2026-11-06-alert-destinations.md

@@ -0,0 +1,26 @@
+---
+title: "Send alerts to Microsoft Teams, Google Chat, incident.io and Linear"
+description: "Four new alert destinations, plus Discord for every organization and the Maple bot in Hazel."
+date: 2026-11-06
+category: alerts
+authors: [makisuo]
+---
+
+Alert rules can now notify more of the tools your team already works in:
+
+- **Microsoft Teams.** Alerts post to a channel through a Workflows webhook, as a card with the
+  state, severity, group, chart and **Open in Maple** and **Ask Maple AI** buttons.
+- **Google Chat.** Alerts post to a space as a card with the chart. A resolve or reminder replies
+  in the thread its trigger started.
+- **incident.io.** Maple raises an alert on an HTTP alert source and resolves it when the incident
+  clears. The rule, severity, value and group come along as metadata your routes can match on.
+- **Linear.** Instead of a message, Maple keeps one issue per rule and group in the team you pick.
+  A repeat fire comments on it, a resolve comments and leaves it open for your team to close, and
+  a fire within 24 hours of closing reopens it. Add Linear to a rule's critical tier only to
+  ticket just the serious incidents.
+
+The **Discord** integration is now open to every organization, and the Maple bot is available in
+**Hazel**. In both, alerts post to a channel and you can ask Maple questions in a thread.
+
+Every destination has a **Send test** button. Set them up from the **Routing** tab in Alerts, and
+see [Notification destinations](/docs/alerting/notification-destinations) for each one.

apps/landing/src/content/changelog/2026-11-06-metrics-group-by.md

@@ -0,0 +1,24 @@
+---
+title: "Group metrics by several labels at once"
+description: "The metrics builder now aggregates within each series and then across series, grouped by up to five fields."
+date: 2026-11-06
+category: dashboards
+authors: [makisuo]
+---
+
+The metrics query builder now aggregates in two steps, the way metrics are usually read:
+
+1. **Within each time series**: `avg`, `sum`, `min`, `max`, `count`, `latest`, `rate` or
+   `increase` over each interval.
+2. **Across time series**: `sum`, `avg`, `min`, `max` or `count`, grouped by up to five fields
+   at once, mixing `service.name`, metric attributes and resource attributes.
+
+So "memory summed over pods, by namespace and job" or "requests per second by namespace and host"
+is now one builder query instead of SQL.
+
+This also fixes grouped metric charts:
+
+- Series that report more often no longer weigh more in an average.
+- A grouped line no longer jumps between services' values from one bucket to the next.
+- A `rate` in a widget no longer comes out 60 times too low on a one-minute bucket.
+- Pie, table and bar breakdowns now agree with the line chart they came from.

apps/landing/src/content/changelog/2026-11-06-slos.md

@@ -0,0 +1,26 @@
+---
+title: "SLOs with burn-rate alerts"
+description: "Set an availability or latency objective on a service, watch its error budget, and get paged when the budget burns too fast."
+date: 2026-11-06
+category: alerts
+authors: [makisuo]
+---
+
+You can now define **service level objectives** in Maple. An SLO covers one service's incoming
+requests, optionally limited to some environments, and has:
+
+- an **SLI**: availability (requests that did not fail) or latency (requests faster than a
+  threshold from 50 ms to 10 s);
+- a **target**, such as 99.9%;
+- a rolling **window** of 7, 28 or 30 days.
+
+Each SLO alerts on how fast it spends its error budget, not on single spikes. A **critical** page
+fires when the budget burns at 14.4 times the sustainable rate over both the last hour and the last
+5 minutes. A **warning** fires at 6 times over both the last 6 hours and 30 minutes. A brief blip
+does not page, and the page clears as soon as the burn stops. The notification says which windows
+are burning and how fast. A gap in incoming data holds the alert where it is instead of resolving
+it.
+
+Find SLOs under **Alerts → SLOs**. Each SLO's page shows the SLI against the target, the budget
+left, the budget over time, the burn rate of each window, and its incidents. SLOs are also
+available from the `/v2/slos` API and MCP.