> For the complete documentation index, see [llms.txt](https://docs.controltheory.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.controltheory.com/controltheory-documentation/dstl8-docs/canvas.md). # Canvas Dashboards you describe to Möbius, and then keep, tweak, and share A canvas is a dashboard of live panels — charts, stats, heatmaps, topology, log patterns, incidents — that you build by describing what you want to see. Ask Möbius for "the cart service's errors and its noisiest patterns over the last hour" and it lays out the panels for you. Every panel fetches its own data, so a canvas is always current: Möbius chooses what each panel looks at, never what the numbers are. Canvases are part of Möbius: if your organization has Möbius Chat, it has Canvas, unless an administrator has turned Canvas off (see [For administrators](#for-administrators)). Open **Canvas** in the left navigation to see yours. ### Building a canvas with Möbius Möbius Chat builds canvases from any page — open the chat sidebar from the header and ask. You don't have to go anywhere first: * **From the page you're on.** Looking at an incident and want its impacted objects on one screen? Ask. Möbius looks the incident up, then builds a canvas scoped to it. The chat shows the canvas as a card while it builds, with an **Open** link when it's ready. * **On a canvas.** With a canvas open, the chat edits *that* canvas: "make the error chart full width", "add a pie of errors by namespace", "only show checkout", "change the window to the last 24 hours". Edits land on the page as Möbius makes them. * **About what you selected.** Click a heatmap cell, a bar, or a chart series and a chip appears above the chat input. Your next question is about that selection — "why is this spiking?" — and "focus on this" narrows the whole canvas to that moment and object. Say *canvas* or *dashboard* when you want one built. Asked a plain question ("which pod of checkout is failing?"), Möbius answers it in the chat instead. ### Other ways in * **Incidents** — **Build canvas** on an incident page makes a canvas for that incident: its impacted objects, their error rates, the patterns and events around it, and the topology between them. Once it exists, the same button opens it. * **Workspace dashboard** and **source pages** — **Open in Canvas** turns the page's panels into a canvas you can rearrange, narrow, and add to. * **Templates** — the gallery's **Templates** tab has starters: Workspace overview, Error hot spots, Incident triage, and Ingestion health. Opening one gives you your own copy to change. ### What a panel can show | Panel | Shows | | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Time series, bar, pie, treemap, radar | Log volume by severity, error ratio, sentiment, anomalies, ingest volume, events — over time or split by service, namespace, pod, deployment, source, and more | | Stat, gauge | One number, optionally against the previous window | | Heatmap | Many groups over time — sentiment or error ratio by service | | Topology graph | Your cluster's objects and how they connect, narrowed to the objects you name | | Service dependencies | Who calls whom, from the [Code Graph](/controltheory-documentation/dstl8-docs/code-graph.md), as a graph or a flow | | Patterns | The log patterns list, with a way into the lines behind each | | Log samples | Recent log lines matching the panel's filters | | Incidents, events | The incidents and events lists, each row linking through | | Anomalies | The anomaly view: what was flagged, when, and why | | Text | A short Markdown note | ### Changing a canvas yourself Everything Möbius does, you can do by hand: * **Add panel** opens the panel editor: pick what it shows, how it's drawn, its filters, and its size. Each panel's menu has **Edit**, **Duplicate**, and **Remove**. * Drag a panel by its header to move it, and drag its corner to resize it. Each kind starts at a sensible size — stats as compact tiles, log lists wide and tall. * The header sets the **time window** (with auto refresh) and the canvas's **scope**: filters every panel follows, so a canvas about one namespace stays about that namespace. * **Variables** add a dropdown to the header — a **service** menu, say — and the panels you choose follow it. Pick a value and those panels narrow to it; leave it empty and they show everything. * Drilling in (a focus from Möbius, **Focus on** in the anomalies list, or clicking a topology node) is a view, not an edit: a pill in the header shows what you've narrowed to, and **Reset** puts it back. Your browser keeps the view for when you come back to the canvas. Canvases save as you go. **Revisions** lists every earlier version, including the ones Möbius wrote, so any change can be undone. ### Sharing A new canvas is private to you. **Share with organization** makes it visible to everyone in your organization; they can open and explore it, and **Save as a new canvas** gives them their own copy to change. Only the owner (or an org admin) can change or delete the original. ### For administrators Canvas comes with Möbius Chat on every plan. To turn it off for your organization, contact support; Canvas then leaves the navigation, and Möbius stops offering to build canvases. --- # 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.controltheory.com/controltheory-documentation/dstl8-docs/canvas.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.