What shipped

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 and the resource reference.

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.

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.

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.

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.

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.

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.

Maple.layer, the long-running preset in @maple-dev/effect-sdk, now accepts the span options that were only on MapleFlush.make and the Cloudflare make. All three presets take the same options and classify spans the same way.

• dropSpanNames drops spans by name prefix, as before. Only the matching span goes.
• dropSpanSubtrees drops a span and every span under it, so an idle polling loop and the queries it runs stop exporting. Outgoing calls under a dropped span carry an unsampled traceparent, and errors inside it are not tracked, so keep real work outside it.
• dropSpan takes a predicate on the finished span (name, kind, attributes, exit), for example to drop only polls that found nothing.
• anticipatedErrorIdentifiers marks expected failures (a duplicate, a not-found) as Ok with no exception, so they stop creating error groups. isAnticipatedError is its predicate form, for driver errors that are only expected in one case.
• excludeLogSpans is now available on Maple.layer too.

A few behaviour changes come with it:

• A server span that answered 5xx stays an error even when its failure is listed as anticipated.
• On Maple.layer, spans for unmatched-route 404s are dropped, and server spans that rendered a 5xx response are recorded as errors, matching the other presets. That can surface new error groups for crashes that used to export as Ok.

Upgrade to @maple-dev/effect-sdk 0.11.0.