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

# Sensors

> A sensor is a standing question about your logs that Sazabi keeps answering, and investigates when the answer turns abnormal.

A sensor is a standing question about your project's logs, such as "are checkouts failing more than usual?" or "did the nightly billing job run?". Sazabi keeps answering it. When the answer turns abnormal, the sensor fires, and the Sazabi agent starts an investigation.

The Sazabi agent sets up sensors for your project and maintains them over time. You don't write or configure sensors yourself.

## What sensors catch

* **Rates and volumes that move:** an error rate that climbs, a latency that shifts, traffic or signups that drop, a jump in log volume.
* **Silence:** a service that goes quiet, or a scheduled job that doesn't report that it finished.
* **Lines that should never appear:** a payment declined for a reason that means a bug, attack payloads, or secrets showing up in your logs.
* **Items that go wrong one at a time:** an agent run that loops on the same tool, or a user session that fails.

A sensor can watch each route, customer plan or job separately, so a failing route fires without the healthy routes firing alongside it.

## How sensors are set up

**Built-in sensors** watch for problems every system can have.

**Sensors the agent writes** cover what only your system knows about: the events, fields and jobs your system actually has, such as a nightly job's schedule or the share of failed calls to a vendor. The agent tests each sensor against your recent history before keeping it, so sensors that would fire on normal behavior are rewritten or dropped.

The agent keeps your sensors current as your system changes. It adds sensors for new services, jobs and vendors as they appear in your logs, and rewrites or drops a sensor that keeps firing on normal behavior.

## When a sensor fires

A firing records a **signal** in your project. The signal says what changed, where and when, with the evidence behind it, such as the value beside what is usual or the log lines that matched. Then the agent starts an investigation. It re-measures the change in your logs, works out whether it is a real problem, and opens an [issue](https://docs.sazabi.com/guides/detect/issues.md) when it is. When the change is real but harmless, or the sensor fired on normal behavior, the agent closes the investigation without an issue and notes what the sensor should watch instead.

When the value is back to normal, the sensor records a resolved signal.

List your project's sensor signals with the CLI:

```bash theme={"system"}
sazabi signals list --type sensor
```

## Ask for a sensor

You don't need to ask for sensors, but you can ask for one in plain words when you want a specific question watched. Describe the question, not the query:

* "Tell me when the share of failed Stripe charges goes above its usual level."
* "Tell me if the nightly export job has not finished by 4am UTC."
* "Tell me when OpenAI calls start returning rate-limit errors."
* "Tell me when signups drop below half of a normal Tuesday."

Send these requests to [support](https://docs.sazabi.com/guides/administer/support.md).

## Turning sensors off

To turn sensors off for a project, [contact support](https://docs.sazabi.com/guides/administer/support.md). Its sensors then stop running and any open firings resolve. Your signals and issues from earlier firings stay in the project.

## Further reading

> [card] [sazabi signals](https://docs.sazabi.com/reference/cli/signals.md)
>
> List and inspect your project's signals from the CLI.

> [card] [Route notifications](https://docs.sazabi.com/guides/detect/notifications.md)
>
> Decide which issues reach which channels.


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