# Using the dashboard

How to read and act on what BugWatch has collected. The pages under [Install an SDK](/install-an-sdk) and [Mobile](/mobile) cover getting data in; these cover working with it once it is there.

| Page | Answers |
|------|---------|
| [Projects](/projects) | What a project is, when to create a new one, how environments work |
| [Project members](/project-members) | Who can see and act on the data |
| [Issues](/issues) | How errors are grouped, how to triage them, how to read a stack trace |
| [Logs](/logs) | Live tail vs search, sending logs, correlating them with errors |
| [Releases](/releases) | Crash-free rate and whether a version is stable |
| [Alerts](/alerts) | Rule types, scoping, evaluation, incidents |
| [Insights](/insights) | Volume, error rate, peaks and the issues driving them |
| [Traces](/traces) | Following one request across services, and reading a span timeline |
| [Metrics](/metrics) | Time series, labels and cardinality |
| [Service map](/service-map) | Which services call which, derived from traces |
| [SLOs](/slos) | Objectives and error budgets |
| [Project settings](/project-settings) | Keys, environments, deletion |

Two related pages live elsewhere because they are CI concerns rather than dashboard ones: [Source Maps & Symbols](/source-maps-symbols) for making production stack traces readable, and [Deployments (CI/CD)](/deployments-ci-cd) for correlating error spikes with what you shipped.