> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/engineering/development-process/how-to-build/tickets/monitoring.md). # Monitoring The permanent home ticket of a feature area, and what goes into it. Owner: Jeremy A monitoring ticket is the permanent home of a feature area. Even when all work under it is finished, its owner stays responsible for the area. ## Rules * The person who built a feature owns it. * The person who built it maintains it through its monitoring ticket. When a rollout ticket is done, new issues go there. The monitoring ticket is never closed. * There is one monitoring ticket per Product Owner area, and one per repository for its maintenance, owned by its Code Owner. If someone else owns the area's monitoring ticket, the Product Engineer who built a feature creates a monitoring ticket for that feature as a sub-ticket of the area's one. * If the person who built a feature has left the team, or the feature is older than monitoring tickets, the Product Owner of its area owns it. If it is unclear which Product Owner that is, or the feature is too technical, the Code Owner owns it. ## The home of a feature area **Its title starts with `[MONITORING]` instead of `[ROLLOUT]`**, and it carries the [name customers and our documentation use](/engineering/development-process/how-to-build/tickets.md#public-names) for the area, for example Bridges. **Every monitoring ticket has one owner.** Do not split a monitoring ticket only because it grew. **Everything that arrives once the rollout ticket is done goes here**: Sentry issues, bugs, tech debt, security issues and feature requests. Bugs, tech debt and security issues go under their [sub-tickets](/engineering/development-process/how-to-build/tickets.md). Once enough has collected, a new rollout ticket is cut out of it. **Alerts on its** [**stability target**](/engineering/development-process/how-to-build/tickets/rollout.md#success) **tell the owner when something needs attention.** ## The description **A monitoring ticket uses the** [**rollout ticket**](/engineering/development-process/how-to-build/tickets/rollout.md#template) **structure.** It keeps the Owner and Features lines, a short Problem, the targets for after the rollout and the [dashboard](/engineering/development-process/how-to-build/tickets/rollout.md#dashboard). It has no What we are shipping, no breadboard and no What we are NOT shipping. **Its stability target is an accepted error baseline.** The rollout ticket sets that number. When the rollout ticket is done, this ticket takes it over and keeps it for as long as we ship the feature. The errors that count are the ones whose [`feature` tag](/engineering/development-process/how-to-build/coding-standards/architecture/error-management.md#feature-tags) is on its Features line. **Its adoption target is read from the** [**rollout ticket's dashboard**](/engineering/development-process/how-to-build/tickets/rollout.md#dashboard)**, set up as** [**Product analytics**](/engineering/development-process/how-to-decide-what-to-build/signals/product-analytics.md) **describes.** **When a fix under it needs a feature flag, it goes through the same** [**stages**](/engineering/development-process/how-to-ship.md#stages-and-the-feature-flag) **as a rollout ticket.** That includes the sign-offs and the CTO's approval before the flag goes on by default. --- # 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://engineering.umh.app/engineering/development-process/how-to-build/tickets/monitoring.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.