---
title: Tempo 3.1 release: new features for Kafka, TraceQL metrics updates, trace redaction, and more
source: Grafana Blog
source_slug: grafana
url: https://grafana.com/blog/tempo-3-1-release-all-the-latest-features/
published: 2026-10-01
fetched: 2026-10-01T14:50:48+00:00
ingested: true
---

Tempo 3.1 adds several community-contributed improvements to Kafka-based ingestion, with new options to secure connections, reduce data transfer costs, and support more Kafka-compatible backends. 

### TLS and more SASL mechanisms

Tempo 3.0 _[moved microservices-mode ingestion onto Kafka](https://grafana.com/blog/tempo-3-0-release-all-the-latest-features/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#splitting-the-read-and-write-path)_ , and the client it shipped with could authenticate, but only with SASL `PLAIN` and only over an unencrypted connection. It had no TLS settings, so a broker that requires TLS would refuse the connection. Tempo 3.1 adds TLS and four more mechanisms: `SCRAM-SHA-256`, `SCRAM-SHA-512`, `OAUTHBEARER`, and `AWS_MSK_IAM`.

Copy
    
    
    ingest:
      kafka:
        address: kafka.example.com:9093
        topic: tempo-traces
        sasl_mechanism: SCRAM-SHA-512
        sasl_username: ${KAFKA_USERNAME}
        sasl_password: ${KAFKA_PASSWORD}
        tls_enabled: true
        tls_ca_path: /etc/tempo/kafka-ca.pem
        tls_cert_path: /etc/tempo/kafka-client.crt   # optional, for mTLS
        tls_key_path: /etc/tempo/kafka-client.key    # optional, for mTLS

Pass `-config.expand-env=true` to expand the environment variables.

Thanks to _[@heytrav](https://github.com/heytrav)_ for this contribution. To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7586)_ and the _[Configure authentication and TLS](https://grafana.com/docs/tempo/latest/set-up-for-tracing/setup-tempo/configure-kafka/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#configure-authentication-and-tls)_ docs.

### Rack-aware fetching

Tempo always fetched from the partition leader, wherever it happened to live. When the leader sits in another availability zone, every trace you read crosses a zone boundary, and your cloud provider bills you for the transfer.

The new `client_rack` option helps reduce those costs by enabling rack-aware fetching (KIP-392), so consumers can read from a replica in their own zone:

Copy
    
    
    ingest:
      kafka:
        client_rack: us-east-1a

This is a read-side setting, so it applies to block-builders, live-stores, and metrics-generators, not to the distributor writing records into Kafka. Your brokers need rack IDs configured for it to take effect.

Thanks to _[@KyriosGN0](https://github.com/KyriosGN0)_ for this contribution. To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7594)_ and the _[ingest configuration](https://grafana.com/docs/tempo/latest/configuration/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#ingest)_ docs.

### Configurable producer compression

Tempo's distributor compresses every batch it writes to Kafka, and until 3.1, the codec wasn't configurable. That's fine unless your backend accepts only one codec: for example, Azure Event Hubs supports the Kafka protocol but accepts only `gzip`, which ruled it out as a Tempo backend.

The new `producer_compression` option lets you pick from `none`, `gzip`, `snappy`, `lz4`, or `zstd`:

Copy
    
    
    ingest:
      kafka:
        producer_compression: gzip

Together with the TLS support above, this option makes Event Hubs a usable Kafka backend for Tempo. If you leave `producer_compression` unset, the Kafka client uses `snappy` by default. If your backend doesn’t support `snappy`, set `producer_compression` to a supported algorithm, or set it to `none` to disable compression.

Thanks to _[@fleighton](https://github.com/fleighton)_ for this contribution. To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7691)_ and the _[ingest configuration](https://grafana.com/docs/tempo/latest/configuration/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#ingest)_ docs.

## Protect sensitive data: redact traces with a TraceQL query

In Tempo 3.0, _[we added trace redaction](https://grafana.com/blog/tempo-3-0-release-all-the-latest-features/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#trace-redaction-to-protect-sensitive-data)_ , allowing you to permanently remove sensitive data, such as an email address, an auth token, or an account number that ended up in a span attribute, from your trace data without waiting for retention to expire. But `tempo-cli redact` only accepted trace IDs, so you had to enumerate every affected trace. Sensitive data usually lands in whatever traffic hits a given code path, which can be more traces than you can practically list. Any trace you miss is data still sitting in object storage, and potentially queryable.

Now, with Tempo 3.1, you can redact using a TraceQL query instead:

Copy
    
    
    tempo-cli redact \
      --tenant=<TENANT_ID> \
      --query '{span.attribute = "<leaked PII>"}' \
      --dry-run \
      <SCHEDULER_ADDRESS>:<GRPC_PORT>

Start with `--dry-run`, as shown above. Tempo evaluates the query and counts what it would remove without modifying any blocks. The command prints the batch ID and the number of jobs created. Job counts and how many traces were matched or removed are per-tenant metrics that can be seen on the Redaction row of the _[Backend Work dashboard](https://grafana.com/docs/tempo/latest/operations/monitor/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ , which ships with Tempo's monitoring mixin. Once the count matches what you expect, run the same command without `--dry-run` to rewrite the blocks. This cannot be undone.

Because a wrong query permanently deletes data you didn't mean to remove, we're deliberately keeping the accepted syntax small for now: a single spanset filter with equality comparisons against `resource.*` and `span.*` attributes, combined using `&&` and `||`. Anything outside that is rejected when you submit the job. We are continuing to improve this functionality.

If you know the time range where data needs to be redacted, you can use it to run the job faster and more efficiently. This is important in high-volume installs because Tempo holds compaction off for a tenant while a redaction is applying. Use `--start` and `--end`, which accept `now`, a relative offset like `now-7d`, or an RFC3339 timestamp. Compaction catches up between runs.

**Note:** Only use `--start` and `--end` once every scheduler and worker in your cell is running at least Tempo 3.1. An older worker ignores the window and removes every query match in each block it is given, regardless of timestamp, with no error and no way to recover the data.

To learn more, see the query selector _[PR](https://github.com/grafana/tempo/pull/7663)_ , the time range _[PR](https://github.com/grafana/tempo/pull/7702)_ , and the _[Redact traces](https://grafana.com/docs/tempo/latest/operations/tempo_cli/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#redact-traces)_ docs for the full query syntax and constraints.

## Query trace metrics with greater accuracy, flexibility, and speed: updates to TraceQL metrics

In Tempo 3.0, _[TraceQL metrics became generally available](https://grafana.com/blog/tempo-3-0-release-all-the-latest-features/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#deeper-insights-trace-ql-metrics-is-now-ga)_ , letting you query ad-hoc metrics directly from trace data. This makes it easier to answer questions about performance, error rates, and service behavior across distributed systems.

With the 3.1 release, we’re rolling out several updates that make TraceQL metrics more flexible and efficient, and more accurate when working with sampled trace data. 

### Sampling-aware metrics queries

Let’s say you _[sample](https://grafana.com/docs/grafana-cloud/observe-and-act/send-data/traces/configure/sampling/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ 50% of your traces before they reach Tempo. If you ran a `rate()` query against a service, you would get half the traffic it actually served, because Tempo counts only the spans that made it through sampling.

This is especially useful with _[Adaptive Traces](https://grafana.com/docs/grafana-cloud/observe-and-act/adaptive-telemetry/adaptive-traces/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ and other _[tail sampling](https://grafana.com/blog/capture-high-value-traces-without-managing-a-pipeline-tail-sampling-with-adaptive-traces/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ setups, where sampling rates can vary across services. With sampling-aware queries, TraceQL metrics can account for those differences and more accurately reflect the underlying traffic.

With Tempo 3.1, you can correct for sampling at query time with the new experimental `with(extrapolate=true)` hint:

Copy
    
    
    { } | rate() with(extrapolate=true)

Samplers that implement OpenTelemetry's _[probability sampling specification](https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/)_ , which is still in development and not supported in every language yet, stamp the rate they sampled at onto the span, in a field called `tracestate`. The hint reads that rate back and scales the span accordingly. At 50% sampling, each stored span counts as two, so a query that matches 1,000 spans reports 2,000. Spans that arrive with no sampling rate recorded count as one, which means partial adoption is safe: if only two of your services sample, the other services' numbers don't change.

Nothing new is written to your blocks. `tracestate` is already stored with every span, and queries that don't use the hint don't read it. If you already correct for sampling in the metrics-generator by setting `enable_tracestate_span_multiplier`, which we [added](https://github.com/grafana/tempo/pull/6684) in Tempo 3.0, the query path reads the rate the same way, so an ad-hoc query and your pre-aggregated `tempo_spanmetrics_*` series agree.

Extrapolation applies to `rate`, `count_over_time`, `sum_over_time`, `avg_over_time`, `histogram_over_time`, `quantile_over_time`, and `compare`. It doesn't apply to `min_over_time` or `max_over_time`, because sampling doesn't change the smallest or largest value you actually observed.

**Note:** This hint is experimental and requires vParquet4 blocks or later.

To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7452)_ and the _[TraceQL metrics functions](https://grafana.com/docs/tempo/latest/metrics-from-traces/metrics-queries/functions/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#extrapolation-from-ingest-time-sampling-withextrapolatetrue-experimental)_ docs.

### Combine metrics queries with arithmetic

Many of the metrics you want to derive from traces require combining two metrics queries rather than running just one. A common example is error rate. Traditionally, TraceQL could measure errors and total traffic separately but couldn't divide one by the other, so you’d have to run two queries and divide them with a math expression in Grafana.

With Tempo 3.1, you can write the division in TraceQL itself. The operators `+`, `-`, `*`, and `/` work between two metrics queries, so an error rate is one query:

Copy
    
    
    ({ status = error } | rate() by (resource.service.name)) / ({ } | rate() by (resource.service.name))

If you group your queries, two series combine only when their label sets match exactly, and a side with no labels is broadcast across every series on the other side. 

You can combine `with(extrapolate=true)` and arithmetic. One hint at the end of the expression applies to both sub-queries:

Copy
    
    
    ({ status = error } | rate()) / ({ } | rate()) with(extrapolate=true)
    

The hint has to go at the end. Putting `with(...)` inside a sub-query is a syntax error.

To learn more, see the arithmetic _[PR](https://github.com/grafana/tempo/pull/6866)_ , the scalars _[PR](https://github.com/grafana/tempo/pull/7199)_ , and the _[arithmetic expressions](https://grafana.com/docs/tempo/latest/metrics-from-traces/metrics-queries/functions/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#arithmetic-expressions)_ docs, and the _[July Community Call](https://www.youtube.com/live/n9mBEd00D1s?si=Kzdrc8VHhA9jgQ_O)_.

### Faster metrics queries by default

Metrics queries are also faster: we've seen simple ones run close to twice as fast. The span-only fetch path we introduced as experimental in Tempo 3.0 is now on by default for vParquet5 blocks, which is what Tempo 3.1 writes. 

Queries that don't need the full trace structure now process individual spans instead of whole traces, which reduces latency and memory use. In one warmed-up test, `{ } |` `rate()` with span-only fetch enabled completed in slightly over half the time it took with span-only fetch disabled. You don't have to change your queries to use it, and you can opt out per tenant or per query if needed.

To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7179)_ and the _[faster read path](https://grafana.com/docs/tempo/latest/metrics-from-traces/metrics-queries/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#faster-read-path)_ docs.

## Enhancements to the metrics-generator

 _[Metrics-generator](https://grafana.com/docs/tempo/latest/metrics-from-traces/metrics-generator/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ is an optional Tempo component that derives metrics from ingested spans, giving you both RED (Rate/Error/Duration) metrics and service graphs, which show the relationships between your services. Here we cover a few of the improvements to metrics-generator included in Tempo 3.1, but please refer to the _[changelog](https://github.com/grafana/tempo/releases#release-v3.1.0)_ and _[release notes](https://grafana.com/docs/tempo/latest/release-notes/v3-1/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ for the complete list.

### See why your service map is missing edges

Tempo builds a service graph edge by pairing the client and server spans for a connection. When one side never arrives, the edge expires and leaves a hole in your map, and you can't tell a connection that doesn't exist from one Tempo couldn't match.

In Tempo 3.1, we added an `unmatched_span_kind` label to the expired edges counter, so you can see which side went missing. A lot of expired edges labeled `SPAN_KIND_SERVER`, for example, point to server-to-server instrumentation that will never resolve into a node.

To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7709)_ , the _[service graphs](https://grafana.com/docs/tempo/latest/metrics-from-traces/service_graphs/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ docs, and the _[expired edges](https://grafana.com/docs/tempo/latest/troubleshooting/metrics-generator/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#expired-edges)_ troubleshooting docs.

### Recognize `db.system.name `from updated OTel semantic conventions

OpenTelemetry _[semantic conventions](https://opentelemetry.io/docs/specs/otel/semantic-conventions/)_ v1.30.0 renamed the `db.system` attribute to `db.system.name`. Instrumentation that emits only the new name stopped being recognized as a database call, so those nodes disappeared from your service map after an SDK upgrade, with no error to tell you.

Tempo 3.1 accepts both attributes for identifying database requests and for naming virtual nodes. When a span carries both, `db.system` takes precedence, so upgrading your SDKs won't rename the nodes your dashboards and alerts already point at.

Thanks to _[@iamrajiv](https://github.com/iamrajiv)_ for this contribution. To learn more, see the _[PR](https://github.com/grafana/tempo/pull/7697)_ and the _[database name attributes](https://grafana.com/docs/tempo/latest/metrics-from-traces/service_graphs/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#database-name-attributes)_ docs.

### Cut per-span metrics-generator costs

The generator processes every span you ingest, so per-span work sets the floor on what it costs to run. Building label sets accounted for a significant share of that work.

The span-metrics and service-graphs processors now borrow pooled label buffers from the registry instead of allocating new ones each time, and our steady-state service-graphs benchmarks report zero allocations per operation. Metric names, labels, and values are unchanged, so you won't see a difference in your dashboards, just generator CPU and memory you no longer have to provision.

To learn more, see the _[span metrics PR](https://github.com/grafana/tempo/pull/7498)_ and the _[service graph PR](https://github.com/grafana/tempo/pull/7587)_.

## Make large traces easier to read with span pruning

A single user request can produce many spans. If your application runs 100 nearly identical database queries behind that request, each one becomes its own span, and you end up with 1 root span and 100 database spans that all look the same. A trace like that is harder to read, and the more queries the request makes, the worse it gets.

With Tempo 3.1, the trace-by-ID v2 endpoint collapses each group of similar leaf spans into a single summary span, which carries `aggregation.span_count` and the minimum, maximum, average, and total duration of the spans it replaced. In the example above, you get back 2 spans instead of 101, in a correspondingly smaller response. Spans only group when their name, kind, status, and parent name match, so an error is never folded in with successes. This happens at read time, so nothing leaves storage.

Ask for it per query:

Copy
    
    
    GET /api/v2/traces/<traceID>?span_pruning=true

Set `span_pruning_enabled_by_default` to `true` in your Tempo configuration, and you won’t need to pass `span_pruning` on each request:

Copy
    
    
    query_frontend:
      trace_by_id:
        span_pruning_enabled_by_default: true

That also covers the Grafana UI and the Tempo MCP server's `get-trace` tool, neither of which sends the parameter yet. An explicit `span_pruning` in a request still takes precedence, so a caller that needs the complete trace can always ask for it. You can also set that default per tenant.

We also added TraceQL filter support to the trace-by-ID v2 endpoint. It takes a single spanset filter on the `q` parameter, so you can fetch one trace and get back only the spans that match instead of all of them. Those spans come back on their own by default; add `keep_hierarchy=true`, and you get each match's ancestor path to the root too.

Copy
    
    
    GET /api/v2/traces/<traceID>?q={ span.http.status_code = 500 }&keep_hierarchy=true

The `gcx` CLI _[is being updated to expose](https://github.com/grafana/gcx/pull/1250)_ both on `gcx traces get`: `--prune` for pruning and `--filter` for the query.

**Note:** Span pruning is experimental. The `span_pruning` parameters, their behavior, and the response format may change in future releases.

To learn more, see the trace pruning[ ](https://github.com/grafana/tempo/pull/7566)_[PR](https://github.com/grafana/tempo/pull/7566)_ , the filter _[PR](https://github.com/grafana/tempo/pull/7483)_ , the[ ](https://grafana.com/docs/tempo/latest/api_docs/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#query-v2)_[Query V2](https://grafana.com/docs/tempo/latest/api_docs/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#query-v2)_ API docs for the request parameters, the[ ](https://grafana.com/docs/tempo/latest/configuration/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#query-frontend)_[query-frontend](https://grafana.com/docs/tempo/latest/configuration/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#query-frontend)_ configuration docs, and the _[August community call](https://www.youtube.com/watch?v=FGpuZ4ul2hQ&list=PLDGkOdUX1Ujqe8WZ8T1h2pNjpll0t-KLw&index=1)_.

## Make trace comparisons faster and more efficient for AI****

Sometimes you want to compare two traces: an endpoint got slower after a deploy, and you have one trace from before and one from after, or the same request succeeds for one caller and fails for another. Either way, comparing them by hand means scrolling through two traces looking for the span that changed, appeared, or disappeared.

With Tempo 3.1, you can use traces diff to send two trace IDs to the query-frontend and get back what changed, instead of pulling both traces and comparing them yourself. This creates a much smaller context window for an LLM, too, which makes AI-driven investigations faster and cheaper:

Copy
    
    
    POST /api/v2/traces/diff

Copy
    
    
    {
      "base": { "traceId": "<BASE_TRACE_ID>" },
      "compare": { "traceId": "<COMPARE_TRACE_ID>" }
    }
    

By default, you get a span-level patch listing every span that was added, removed, or modified. Partial traces are rejected, since spans missing from an incomplete trace would look like spans that were removed.

You can also ask for a summary instead of the patch. It reports whether trace latency, errors, and span count went up or down, whether the structure changed, and which services were involved, with a millisecond delta for the ones that moved. It tells you which direction each number moved, not whether that's a regression. A trace that got faster might just be failing earlier.

The summary also catches drift that the patch filters out. When every span in a service is slightly slower, no single span clears the per-span tolerance, but the service's summed span duration does, so the service still shows up as changed.

There are multiple tools you can use to get the traces diff. The _[gcx CLI](https://github.com/grafana/gcx)_ wraps the API in an experimental `gcx traces diff`, so you can compare two IDs from the terminal without fetching either trace yourself:

Copy
    
    
    gcx traces diff --context prod -d <DATASOURCE_UID> <BASE_TRACE_ID> <COMPARE_TRACE_ID>

`tempo-cli experimental traces-diff` diffs two local trace JSON files instead, which is handy when you've already exported them. It emits the patch by default, and you can get the summary with `--format`. The _[Tempo MCP server we added in 2.9](https://grafana.com/blog/grafana-tempo-2-9-release-mcp-server-support-traceql-metrics-sampling-and-more/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#analyze-tracing-data-with-llms-mcp-server-support)_ now includes a `traces-diff` tool that returns the summary first, so an AI assistant connected to Tempo gets a usable answer without always pulling back a large patch.

**Note:** This endpoint is experimental. The request and response formats may change in future releases.

To learn more, see the _[API PR](https://github.com/grafana/tempo/pull/7523)_ , the _[CLI PR](https://github.com/grafana/tempo/pull/7468)_ , the _[MCP PR](https://github.com/grafana/tempo/pull/7785)_ , the _[traces diff](https://grafana.com/docs/tempo/latest/api_docs/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#traces-diff)_ API docs, the _[experimental traces diff](https://grafana.com/docs/tempo/latest/operations/tempo_cli/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#experimental-traces-diff)_ Tempo CLI docs, the _[gcx traces diff](https://github.com/grafana/gcx/blob/main/docs/reference/cli/gcx_traces_diff.md)_ reference, and the _[Compare traces](https://grafana.com/docs/tempo/latest/api_docs/mcp-server/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#compare-traces)_ Tempo MCP docs.

## Improved query performance and lower memory usage: vParquet5 is now the default block format

Tempo stores traces in the Apache Parquet columnar block format, and continues to iterate on the layout for better performance and efficiency. We _[introduced](https://grafana.com/blog/tempo-2-10-release-all-the-latest-features/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#v-parquet5-brings-new-features-to-tempo)_ vParquet5 as an opt-in format in Tempo 2.10, and in 3.1, it becomes the default.

The faster metrics read path mentioned earlier in this post is one payoff of the new default. It's implemented for vParquet5 only, and Tempo falls back to the standard path for blocks in older formats, so your metrics queries get faster as new blocks accumulate. Another payoff is that newly written blocks support the `span:childCount` intrinsic. We added it in 2.10, but only vParquet5 supports it, so previously you had to opt into vParquet5 to use it.

vParquet5 also offers more customization for the way the Parquet columns are configured. You can now have twice as many dedicated columns for strings, support for integers, and very long or high-cardinality strings (known as "blobs"), at each of resource, span, and event levels. The best way to take advantage of this is to use the new `tempo-cli` command `suggest columns`. It will analyze your data and tell you the optimal layout, and make it easy to copy and paste the output into your Tempo configuration. 

To learn more about the features vParquet5 brings, see the docs for _[dedicated columns](https://grafana.com/docs/tempo/latest/operations/dedicated_columns/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ and the _[vParquet5 section](https://grafana.com/blog/tempo-2-10-release-all-the-latest-features/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text#v-parquet5-brings-new-features-to-tempo)_ of the Tempo 2.10 release blog post. You can also see the _[PR](https://github.com/grafana/tempo/pull/7775)_ and the _[Apache Parquet block format](https://grafana.com/docs/tempo/latest/configuration/parquet/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ docs.

## How to learn more

To see the full list of improvements, bug fixes, and breaking changes in Tempo 3.1, please refer to the _[release notes](https://grafana.com/docs/tempo/latest/release-notes/v3-1/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ and _[changelog](https://github.com/grafana/tempo/releases#release-v3.1.0)_. Before you upgrade, please review _[Upgrade your Tempo installation](https://grafana.com/docs/tempo/latest/set-up-for-tracing/setup-tempo/upgrade/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ for the changes that need action.

If you are interested in hearing more about Tempo news, please join us on the _[Grafana Labs Community Slack](https://slack.grafana.com/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ channel #tempo, post a question in our _[community forums](https://community.grafana.com/c/grafana-tempo/?pg=tempo-3-1-release-all-the-latest-features&plcmt=in-text)_ , or join our monthly _[Tempo community call](https://docs.google.com/document/d/1yGsI6ywU-PxZBjmq3p3vAXr9g5yBXSDk4NU8LGo8qeY/edit#)_. See you there!