Skip to main content
GreenSlope

Changelog

An honest record of every customer-facing change — new capabilities, behaviour changes, security fixes, deprecations. We list them the same way: short, factual, and with the action required spelled out when there is one. No hype openers, no quiet rewrites, no gated entries.

2026.04
  • Added
  • Changed

Go SDK v0.7 auto-sets service.version from RELEASE_ID.

The Go SDK now sets the service.version resource attribute automatically when the RELEASE_ID environment variable is present, removing the need to wire it manually on Vercel, Fly, Railway, and Render.

Manual configuration still works and takes precedence when both are set — we only fill in the attribute when it is otherwise missing. Existing code keeps working; nothing to change on upgrade.

The Go SDK setup guide now leads with the environment-variable flow and keeps the manual block below it for platforms without a built-in release id.

Affects
Customers using the Go SDK.
2026.04-hotfix-1
  • Changed

Starter tenants now default to 10% trace sampling.

The default trace-sampling rate for newly-created Starter tenants is now 10%, down from the prior 100%. We think the new default is better for most workloads — at Starter volumes, 100% sampling mostly burns ingest budget on redundant copies of the same span shape, and the Doctor page gives you the same coverage at a fraction of the cost.

Error spans, deploy-marker spans, and spans tagged sampling.priority=1 are still always kept. Existing tenants are unchanged — we do not silently edit configured defaults.

If you are mid-setup and want the old behaviour, the sampling rate is a single slider in project settings.

Affects
New Starter-tier tenants. Existing tenants keep their configured sampling rate.
Action required
None for existing tenants. New tenants can raise the rate in project settings if you need full-fidelity traces during early setup.
2026.04-preview
  • Added

Webhook payload adds alert.severity field.

The generic alert webhook payload now includes an alert.severity field with one of sev-1, sev-2, or sev-3. Integrators previously had to derive severity from the SLO configuration the alert fired against, which worked but was fragile across threshold changes.

The field is additive — existing fields are unchanged and integrations that ignore unknown keys keep working without modification. The webhook reference has a full sample payload with the new field in place.

Affects
Customers consuming the generic alert webhook. Slack, Twilio, and email integrations are unaffected — severity has always been visible there.
Action required
None. The new field is additive and does not change existing fields.
2026.03-hotfix-2
  • Fixed

Go SDK no longer truncates in-flight spans on SIGTERM during graceful shutdown.

A SIGTERM during graceful shutdown could close the OTLP exporter before the final flush completed, truncating up to two seconds of in-flight spans. Symptom: the last request of a rolling deploy would appear to have no downstream spans, making it look like the new pod was failing silently when in fact the span data had simply been dropped.

The shutdown path now waits on the flush completion (capped at the configured exporter timeout) before closing the transport. We backfilled the missing spans for affected tenants where the buffered data was still within the 7-day retention window; anything older is unrecoverable.

Thanks to the customer who filed the reproducer — the bug had been latent since v0.5 and was invisible without a tightly-timed rolling restart.

Affects
Customers running the Go SDK on Kubernetes, Nomad, or any platform that sends SIGTERM before SIGKILL.
Action required
Upgrade the Go SDK to v0.6.3 or later. Earlier v0.6 releases will continue to drop spans on shutdown.
2026.03
  • Deprecated

Legacy /webhook/v1 path deprecated; removal scheduled for 2026-09-18.

The /webhook/v1 path will be removed on 2026-09-18 — six months from today, matching the standard deprecation window. /webhook/v2 has been the default since November 2025 and is the path all new tenants use.

We can see from ingest logs that a small number of tenants still post to the v1 path. You will also see a warning banner on the project dashboard until the integration is migrated; the payload continues to be accepted until the removal date.

If the removal date later slips we will announce the slip in a follow-up entry with a new date — the date in this entry is the commitment.

Affects
Customers posting events to the legacy /webhook/v1 path. /webhook/v2 has been the default since 2025-11 and is unaffected.
Action required
Migrate any integrations still using /webhook/v1 to /webhook/v2 before 2026-09-18. The response shape is unchanged; the request shape replaces the ad-hoc `metadata` blob with a typed `attributes` map.
2026.03-security-1
  • Security

Security fix: ingest endpoint rejected malformed JWTs with the wrong error class.

A malformed JWT submitted to the ingest endpoint was returning 500 Internal Server Error instead of 401 Unauthorized. No tenant data was exposed — the token still failed to validate and no downstream processing ran — but the response class was incorrect, and the timing difference between the two paths could in principle have been used as a weak oracle to distinguish a live tenant ingest endpoint from a non-existent one.

The ingest handler now returns 401 Unauthorized with a generic body for every malformed, expired, or unknown-key token. Response timing is now independent of which validation step failed.

The fix is live in all regions. Internal advisory ID: GS-ADV-2026-001.

Affects
All tenants. The bug did not expose tenant data — tokens still failed to validate — but the 500-class response obscured the cause and could be used to distinguish live endpoints from non-existent ones.
Action required
None. The fix is server-side and deployed to all regions.
Advisory
GS-ADV-2026-001
2026.03-preview
  • Changed

Slack incident loop now requires explicit ack for sev-1 before suppressing repeat pages.

Previously an emoji reaction was enough to acknowledge a sev-1 page and stop the repeat loop. We have seen enough cases of a reaction being dropped accidentally — a finger slip, a bot adding an emoji — that we no longer treat reactions as sufficient for a sev-1.

sev-1 acknowledgement now requires either the /gs ack slash command or clicking the Acknowledge button on the alert card. The command logs which human acked, which is also useful during the post-incident review.

sev-2 and sev-3 are unchanged — an emoji reaction still acks a sev-2, and sev-3 does not loop at all.

Affects
Customers using the Slack integration for sev-1 paging. sev-2 and sev-3 behaviour is unchanged.
Action required
None for most teams. If you relied on a reaction-based ack for sev-1, switch to the `/gs ack` command — reactions still work for sev-2 and sev-3.
2026.02
  • Changed

Neon added as a sub-processor for metadata storage.

We have added Neon as a sub-processor for Postgres metadata storage (project configuration, API keys, and alert rules — not telemetry data, which stays on the dedicated ingest path). The full list is on /legal/subprocessors and the security page has the updated control matrix.

This is disclosed 30 days ahead of cut-over per our sub-processor notice commitment. No action is required; the migration is operator-side and will not change any tenant-facing behaviour or region.

If a sub-processor change is material to your compliance regime and you need earlier notice on future additions, email security@greenslope.io and we will add you to the direct-notice list.

Affects
All tenants. No customer action is required; the change is listed here for transparency because adding a sub-processor is a customer-facing change.