> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Logs, debugging and Watcher

> Ask what is wrong, read logs and status, and get Slack alerts with a written diagnosis when something breaks

When something breaks, you usually need status, logs and a guess at the cause, from several tools. With Monk you ask in your coding agent. Monk reads status and logs from your cluster, and your coding agent fixes the code or config.

## What you can do

### Ask what is wrong

Ask for status, read the last lines of a service's logs, follow new lines for a short time, or describe a symptom such as a 502 and ask for the cause. Monk returns a bounded tail of logs and checks status and the running configuration. If the cause is in your code, your coding agent makes the fix. Monk doesn't edit application code. Reading status and logs needs no approval.

**How:** Ask Monk. See [Logs and debugging](/guides/logs-and-debugging).

### Open a shell and see resource use

Open a shell in a container, run one command in it, or see CPU, memory and disk per workload or per node.

**How:** In a terminal, with `monk shell`, `monk exec`, `monk stats` and `monk cluster stats`. Your coding agent doesn't run them for you. See [Logs and debugging](/guides/logs-and-debugging).

### Let the orchestrator recover workloads

The orchestrator on your cluster restarts and reschedules the workloads it manages, within its policies and the capacity of your nodes. You can set health checks in your template.

**How:** Automatic; policies and checks are in your Monk config. See [Watcher and recovery](/concepts/watcher-and-recovery).

### Get alerts with a diagnosis

Watcher runs on your cluster and watches for crashes, failing health checks and high CPU, memory or disk use. When something trips, it writes a diagnosis with the log lines around it and can send it to Slack. Defaults suit most clusters, and you can change the thresholds at setup.

**How:** Ask Monk; you review the plan in the local dashboard and connect Slack there. See [Watcher and alerts](/guides/watcher-and-alerts).

### Act on an alert

Open your coding agent and ask Monk about the alert. Any fix Watcher proposes needs a person's approval, and a change goes through the usual plan review in the local dashboard.

**How:** Ask Monk; you approve in the local dashboard. See [Watcher and alerts](/guides/watcher-and-alerts).

## Try it

```
/monk the frontend returns 502, find out why
```

## Good to know

* Slack is one-way. It carries Watcher's notifications. You can't chat with Monk or approve anything from Slack.
* Watcher reports. It doesn't change your deployment by itself.
* Monk doesn't collect application metrics such as queue depth or slow queries.
* Neither the orchestrator nor Watcher rolls back a release or adds machines.
* Watcher's monitoring and diagnosis use watcher credits from your plan.

<CardGroup cols={2}>
  <Card title="Logs and debugging" icon="stethoscope" href="/guides/logs-and-debugging">
    Status, logs and finding the cause
  </Card>

  <Card title="Watcher and alerts" icon="radar" href="/guides/watcher-and-alerts">
    Set up Watcher and Slack
  </Card>

  <Card title="Watcher and recovery" icon="heart-pulse" href="/concepts/watcher-and-recovery">
    What recovers by itself and what Watcher adds
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.