Why one timeline

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.

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.

[[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 uses these relationships to avoid duplicate notifications.

Web app context

With the tracking script, incidents show changes in traffic and JavaScript errors. Deploy 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 matters.