> For the complete documentation index, see [llms.txt](https://docs.digibee.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digibee.com/documentation/release-notes/october-2026/october-20.md). # October 20 ## **Platform Improvements** ### **Data Streaming integration with New Relic** Data Streaming can now send your pipeline execution data to **New Relic**, in addition to Datadog and Splunk. If your company already uses New Relic for observability, you can now monitor your Digibee integrations in the same tool you use for the rest of your systems, without needing a separate solution. With your data in New Relic, it’s easier to correlate pipeline behavior with other applications, identify issues faster, and build dashboards and alerts the way your team already works. To set it up, go to **Settings** and open the **Data Streaming** page, just as you would for the other providers. Set up Data Streaming with New Relic

### **Consumption-Based Model Alerts** You can now get notified by email, Slack, or webhook when your credit consumption reaches a limit you set. Alerts can cover your whole contract, a project, or a single pipeline, so you can track consumption at the level that matters to you. See each alert's status and progress on the new **Alerts** page in **Runtime Compute**. Learn about the Consumption-Based Model

### **Accounts and Globals centralized in Build** **Accounts** and **Globals** are now available only in **Build**, the same area where you create and configure your pipelines. Previously, you could also reach them through shortcuts on the Settings page, which have been removed. With a single access point, you can find and manage these resources right where you use them, without switching between areas. Explore the Build documentation ## **Connectors & Triggers** ### **Time Zone field in 5-Minute and 30-Minute Scheduler Triggers** The 5-Minute and 30-Minute Scheduler Trigger types now include the **Time Zone** field, already available in the Custom and Midnight types. You can now run custom cron expressions in your local time zone instead of UTC. Existing 5-Minute and 30-Minute triggers keep running in UTC until you edit the trigger, save the pipeline, and deploy it again. After the new deployment, the trigger runs in the time zone selected in the Time Zone field, which is `America/Sao_Paulo` by default. If your cron expression uses fixed times, check the Time Zone field before saving and deploying to make sure your pipeline runs at the expected time. See the Scheduler Trigger documentation ### **New default runtime for Script (JavaScript)** The **Script (JavaScript)** connector now runs on the new runtime by default, including in pipelines you have already deployed. The new runtime runs your code inside the pipeline, which makes it faster and removes the dependency on shared script infrastructure. You don’t need to change or redeploy your pipelines to use it. If a script behaves differently on the new runtime, select **Use Legacy Runtime** in the connector to go back to the previous runtime, and contact Support so we can fix the difference. The **Use Experimental Runtime** option has been removed. Read the Script (JavaScript) connector documentation ## **Bug Fixes** * **digibeectl:** Fixed an issue where tokens could be created with an expiration longer than 1 year. The maximum validity is now 365 days, both in the interface and through the API. When you select **Year** as the time unit, the quantity resets to 1 and the token is created with 365 days. Through the API, values above `365` days or `1y` now return an error; use `365d`, for example. Existing tokens are not affected. * **Stream CSV Reader connector:** Fixed an issue where **Inspect Mode** displayed only the first iteration of the onProcess subflow. You can now navigate through all iterations, just as with other loop connectors. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.digibee.com/documentation/release-notes/october-2026/october-20.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.