<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Dynatrace integration using expired jwt token in Alerting</title>
    <link>https://community.dynatrace.com/t5/Alerting/Dynatrace-integration-using-expired-jwt-token/m-p/293287#M6159</link>
    <description>&lt;P&gt;after migration to SAAS , integration on alerts is failing regularly with expired token.&amp;nbsp;&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;I got confirmation of support "&lt;SPAN&gt;To remain efficient and avoid unnecessary calls to Entra ID, Dynatrace caches the JWS token.&amp;nbsp;It continues to use the cached token until the destination returns a&amp;nbsp;401 Unauthorized."&lt;BR /&gt;&lt;BR /&gt;&lt;FONT color="#000000"&gt;Advice :&amp;nbsp;&lt;BR /&gt;&lt;/FONT&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Increase the token lifetime&amp;nbsp; -&amp;gt; Less failures.&lt;/LI&gt;&lt;LI&gt;Edit the anomaly settings for the API-GW service to ignore 401 errors.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;both of the options are not realistic : Increasing the token lifetime will not be allowed by security AND will only decrease but will keep on occurring (but less frequent)&lt;BR /&gt;Anomaly settings on API-GW to ignore 401 errors, would give a false view, as there might be other causes for the 401's wich we would be missing.&lt;BR /&gt;&lt;BR /&gt;Anyone having same experience ?&amp;nbsp; Any idea how to solve ?&amp;nbsp; And why does DT not test on expiration before (re-)using the token ?&amp;nbsp;&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 19 Jan 2026 15:49:20 GMT</pubDate>
    <dc:creator>monique_vanwall</dc:creator>
    <dc:date>2026-01-19T15:49:20Z</dc:date>
    <item>
      <title>Dynatrace integration using expired jwt token</title>
      <link>https://community.dynatrace.com/t5/Alerting/Dynatrace-integration-using-expired-jwt-token/m-p/293287#M6159</link>
      <description>&lt;P&gt;after migration to SAAS , integration on alerts is failing regularly with expired token.&amp;nbsp;&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;I got confirmation of support "&lt;SPAN&gt;To remain efficient and avoid unnecessary calls to Entra ID, Dynatrace caches the JWS token.&amp;nbsp;It continues to use the cached token until the destination returns a&amp;nbsp;401 Unauthorized."&lt;BR /&gt;&lt;BR /&gt;&lt;FONT color="#000000"&gt;Advice :&amp;nbsp;&lt;BR /&gt;&lt;/FONT&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Increase the token lifetime&amp;nbsp; -&amp;gt; Less failures.&lt;/LI&gt;&lt;LI&gt;Edit the anomaly settings for the API-GW service to ignore 401 errors.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;both of the options are not realistic : Increasing the token lifetime will not be allowed by security AND will only decrease but will keep on occurring (but less frequent)&lt;BR /&gt;Anomaly settings on API-GW to ignore 401 errors, would give a false view, as there might be other causes for the 401's wich we would be missing.&lt;BR /&gt;&lt;BR /&gt;Anyone having same experience ?&amp;nbsp; Any idea how to solve ?&amp;nbsp; And why does DT not test on expiration before (re-)using the token ?&amp;nbsp;&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 19 Jan 2026 15:49:20 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Dynatrace-integration-using-expired-jwt-token/m-p/293287#M6159</guid>
      <dc:creator>monique_vanwall</dc:creator>
      <dc:date>2026-01-19T15:49:20Z</dc:date>
    </item>
    <item>
      <title>Re: Dynatrace integration using expired jwt token</title>
      <link>https://community.dynatrace.com/t5/Alerting/Dynatrace-integration-using-expired-jwt-token/m-p/293390#M6164</link>
      <description>&lt;P&gt;Hi,&lt;BR /&gt;i will try answer &lt;span class="lia-unicode-emoji" title=":winking_face:"&gt;😉&lt;/span&gt;&lt;/P&gt;&lt;P&gt;Entra ID access tokens are short-lived and can vary (often ~60–90 minutes by design).&lt;BR /&gt;&lt;A href="https://office365itpros.com/2023/05/29/azure-ad-access-token-lifetime/" target="_blank"&gt;https://office365itpros.com/2023/05/29/azure-ad-access-token-lifetime/&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;I think you can try one of this options:&lt;BR /&gt;First option is create&amp;nbsp;proxy/webhook receiver.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Dynatrace → your proxy endpoint&lt;/P&gt;&lt;P&gt;Proxy handles Entra auth, refreshes proactively (e.g., refresh when &amp;lt;5 minutes left), then calls API-GW.&lt;BR /&gt;No security exceptions, no “ignore 401”, full control (retries, logging, idempotency).&lt;BR /&gt;&lt;BR /&gt;Second option is&amp;nbsp;Use Dynatrace Workflows instead of the legacy notification integration.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Workflows allow:&lt;/P&gt;&lt;P&gt;HTTP Request with Credential Vault, and for advanced auth:&lt;/P&gt;&lt;P&gt;Run JavaScript to fetch a fresh Entra token “just-in-time” and send the request.&lt;BR /&gt;&lt;A href="https://docs.dynatrace.com/docs/analyze-explore-automate/workflows/default-workflow-actions/http-request-workflow-action" target="_blank"&gt;https://docs.dynatrace.com/docs/analyze-explore-automate/workflows/default-workflow-actions/http-request-workflow-action&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Why doesn’t Dynatrace check the token expiry before reuse?&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;tokens aren’t always safely/consistently parseable/usable as a “trustworthy expiry source” across providers,&lt;/LI&gt;&lt;LI&gt;standard integration pattern: use cached bearer → refresh on 401&amp;nbsp;&lt;/LI&gt;&lt;/UL&gt;</description>
      <pubDate>Wed, 21 Jan 2026 13:52:54 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Dynatrace-integration-using-expired-jwt-token/m-p/293390#M6164</guid>
      <dc:creator>t_pawlak</dc:creator>
      <dc:date>2026-01-21T13:52:54Z</dc:date>
    </item>
  </channel>
</rss>

