---
title: "New token scope for monitoring"
excerpt: "New token scope for monitoring, changing timeout HTTP error codes, and more!"
date: "2025-01-10"
---

# New token scope for monitoring

The `ORG_DATASOURCES:READ` scope helps you consume Service Data Sources at the organization level, for example `organization.datasources_ops_log`, in a safer way, without the need of using an admin-level token.

This is useful for organization level monitoring, such as the one provided by the [`tinybird-org-metrics-exporter`](https://github.com/tinybirdco/tinybird-org-metrics-exporter) project template to monitor organization metrics using Prometheus endpoints and Grafana.

You can create a token with the `ORG_DATASOURCES:READ` scope only through the API. To create a token with the new scope, call the Tokens API. For example:

```shell
POST https://api.tinybird.co/v0/tokens/?name=prometheus_org_access&description=optional&scope=PIPES:READ:organization_metrics&scope=ORG_DATASOURCES:READ
```

## Query timeout status code changing from 408 to 504

{% callout type="warning" title="Important" %}
The change of HTTP status code for query timeouts has been canceled for technical reasons. We apologize for the inconvenience this might have caused. See [January 24](/changelog/2025-01-24-january-week-four#change-of-http-status-code-has-been-canceled) for more details.
{% /callout %}

Starting on January 27, 2025, Tinybird will change the HTTP status code returned for query timeouts from `408 (Request Timeout)` to `504 (Gateway Timeout)`.

If your app currently handles `408` errors, you will need to update your code to handle `504` errors instead. Also make sure any automatic retry mechanisms in your app are aligned with the new status code.

We are doing this for the following reasons:

- A `504` code indicates a server-side timeout rather than a client-side one, which better reflects what’s actually happening when a query takes too long.
- Firefox treats a `408` error as a client timeout and automatically retries requests. This caused repeated retries for queries that had legitimately timed out. Switching to 504 resolves this issue.

This change will go live on January 27, 2025. We recommend preparing your apps and exception-handling logic well before that date to ensure a smooth transition. If you have any questions or concerns, reach out through our usual support channels.

## Improvements and bug fixes

- We've streamlined the autocomplete behavior in the query editor when working with multiple Data Sources and Data Source prefixes. For example, `source.column_name` are now only added to column names when necessary to avoid ambiguity between Data Sources.
- When a Data Source is renamed, all your Pipes are updated to use the new name. We've improved the renaming behavior to prevent unintended changes to queries that use similar names for columns or aliases. Renaming a Data Source now only updates the Data Source references while preserving all other naming elements in your queries.
- Fixed a bug in Sink Pipes where parameters weren't being correctly propagated when used in both column conditions and file templates across multiple nodes. This affected scenarios where a parameter was used to conditionally add columns while also being used to determine the output path.