# Why one timeline

How kogut connects uptime checks, host metrics, and deploys through services.

kogut puts checks, host metrics, and deploys on one service timeline, so a deploy, a
container restart, and a failed check can appear in the same incident.

## One incident instead of several alerts

`api` on `vps-1` is deployed at 14:02. Its memory climbs, its container restarts, and its
checks fail from 14:07. kogut sends one message:

> api is down since 14:07 (3 signals failing)
>
> API health failing since 14:07: status 503, expected 2xx.\
> Orders API failing since 14:07: no answer within 10000 ms.\
> Storefront failing since 14:08: status 502, expected 2xx.\
> Likely cause: deploy of api 3f9c2e1 at 14:02.\
> Also affected: website.
>
> Open incident

The message names the top likely cause. The incident page lists up to three, each with
its evidence, such as "the api container on vps-1 restarted" and "memory on vps-1 at
98%". A likely cause is not proof; see [Likely causes](https://docs.kogut.dev/incidents/correlation/).

## Services and signals

Services are what you run, such as `website`, `api`, or `postgres`. Their hosts and
dependencies connect checks to the infrastructure behind them.

```toml title="kogut.toml"
[[service]]
name = "website"
sites = ["acme.com"]
depends_on = ["api"]

[[service]]
name = "api"
hosts = ["vps-1"]
depends_on = ["postgres"]
```

With this, a failure of `website` has context from `api` and `vps-1`.
[Alert grouping](https://docs.kogut.dev/alerts/how-alerts-work/) uses these relationships to avoid duplicate
notifications.

## Web app context

With the tracking script, incidents show changes in traffic and JavaScript errors.
[Deploy reports](https://docs.kogut.dev/deploys/reports/) compare the hour before a deploy with the hour
after it. Neither is needed for server or uptime monitoring.

## The trade-off

The monitor and its status page run in the same process as everything else, so
[where you run kogut](https://docs.kogut.dev/high-availability/setups/) matters.