Fix Durable Objects TTL example where long TTLs lead to infinite alar…

[joshthoward]

…m invocations

Summary

Screenshots (optional)

Documentation checklist

• The documentation style guide has been adhered to.
• If a larger change - such as adding a new page- an issue has been opened in relation to any incorrect or out of date information that this PR fixes.
• Files which have changed name or location have been allocated redirects.

[hyperlint-ai]

Howdy and thanks for contributing to our repo. The Cloudflare team reviews new, external PRs within two (2) weeks. If it's been two weeks or longer without any movement, please tag the PR Assignees in a comment.

We review internal PRs within 1 week. If it's something urgent or has been sitting without a comment, start a thread in the Developer Docs space internally.

---

PR Change Summary

Updated the Durable Objects TTL example to clarify the proper usage of alarms and prevent infinite alarm invocations.

• Added a caution note regarding the use of setAlarm in the Durable Object constructor.
• Clarified that the TTL is extended upon every fetch request, not in the constructor.
• Updated comments in the code to reflect the correct behavior of the TTL implementation.

Modified Files

• src/content/docs/durable-objects/examples/durable-object-ttl.mdx

---

How can I customize these reviews?

Check out the Hyperlint AI Reviewer docs for more information on how to customize the review.

If you just want to ignore it on this PR, you can add the hyperlint-ignore label to the PR. Future changes won't trigger a Hyperlint review.

Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add hyperlint-ignore to the PR to ignore the link check for this PR.