> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/data-developer/operate-your-product.md).

# Operate your product

A deployed product is not done; it is running. Keeping it healthy, current, and trustworthy is the ongoing job, and it is what consumers rely on. This is the developer's slice of the [Observability model](/operate/v1/observability-model.md).

## Watch your runs

Your product reports its own operational signals: run history and status, schedule adherence, quality-check results, and freshness. Watch them as an owner:

* **Runs and schedules.** Confirm scheduled runs complete and on time. A missed or failing run means stale data downstream.
* **Failures.** When a run fails, read the error and the failing model, fix the source data or the logic, and re-run. Plan and audit locally before re-deploying; see [Plan & run](https://v2.dataos.info/build/productize/plan-and-run) in the Build guide.
* **Quality and freshness.** A failing assertion blocked bad data (good); a drifting DQ check warns that something changed. Treat both as signals to act.

## Manage change

Your product has consumers, so changes have a blast radius:

* **Version deliberately.** Bump the product version on meaningful changes so consumers can reason about what they depend on.
* **Sequence breaking changes.** Dropping a column, changing a grain, or renaming a measure breaks consumers. Because the product validates a change against its own semantic and policy surface before it reaches the warehouse, you get caught at author time, but you still owe consumers notice. Communicate, give a migration window, then ship.
* **Promote, do not hotfix.** Roll changes through your environments (see [Deploy and promote](/operate/v1/data-developer/deploy-and-promote.md)) rather than editing production directly.

## Own it

* **Be reachable.** You are the named owner; make sure contact details and the issue path are current, so consumers can reach you (see [Raise issues and track changes](/operate/v1/data-consumer/support-and-changes.md) in the Consumer section).
* **Mind the cost.** Your runs consume Compute. Right-size the Compute your models use, prefer incremental over full rebuilds where data grows, and retire products no one consumes.
* **Keep the contract honest.** The `usage.yaml` (what the product is good for, and not) should stay true as the product evolves.

Consumers judge your product through its published trust signals; keeping those green is what this page is ultimately about. See how they read them in [Trust and monitor](/operate/v1/data-consumer/trust-and-monitor.md) in the Consumer section.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/operate/v1/data-developer/operate-your-product.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.