# Logs, alerts and the weekly digest

See what your apps do, read their logs and numbers, get an alert when something fails or goes quiet, receive a weekly digest, and share a status page.

URL: https://docs.qaldy.com/guides/observe/

You should hear about a problem before your team does. Five pieces share one pipeline.

| Piece | Where | Who | Notes |
|---|---|---|---|
| **Logs** per app and per run, live | The app page, Logs; a run's drawer | People who can **edit** the app | Platform lines exist for every run. App console lines need the runtime host's telemetry [[Preview]] |
| **Metrics**: requests, errors, p50 and p95, CPU | The app page, Traffic | Anyone who can **view** the app | Latency percentiles are estimates; CPU time may read "Not measured here yet" |
| **Alerts** and their history | Alerts | Workspace **admins** | Email, and Telegram through the workspace's own bot |
| **Weekly digest** | Monday, 06:00 UTC | Owners and admins, unless they unsubscribe | Sent by email |
| **Public status page** | An address you share | Anyone with the link; on or off per workspace | Built from what Qaldy recorded |

![The Analytics screen: runs per day by outcome, failure rate, run times, hours saved and connector health for the apps you can open.](https://docs.qaldy.com/screens/analytics.webp "Analytics shows runs, failures and time saved for the apps you can open. Sample data.")

## What is real, and how it is measured

Nothing here is invented. Where a number does not exist yet, the screen says so.

- **Platform lines** (a run started, finished or failed, a gate decision) are written by the control plane in the same transaction as the event they describe.
- **App console lines, request outcomes and CPU time** come from the runtime host. After each response it reports the status and the duration, never the URL, a header or a body. Reports are redacted at the host, signed and sent in batches; a failed report is dropped, so telemetry never queues behind a sick API or slows an app. Console lines and CPU time have been checked in a local runtime and not yet on Cloudflare.
- **Latency** is kept in a coarse histogram, so p50 and p95 are estimates. Run durations are exact.
- **The status page** reports what Qaldy recorded: app status, runs and open alerts. It is not an outside probe, and the page says so. Apps sit behind your company login, so an outside probe could not see them.

Logs are kept 7 days (the newest 5,000 lines per app), metrics 14 days. A line is redacted twice, at the host and at the API, and at most 300 lines a minute are kept per app; the next minute says how many were dropped. Logs are readable by people who can edit the app; a read token can read them over the API.

## Alerts

Three rules, judged every minute:

- **Errors above a line:** failed or blocked runs plus server errors, as a share of everything in a window (15 minutes, 1, 6 or 24 hours), with at least a set number of events so one failure in a quiet hour is not "100 percent".
- **App quiet for N hours:** no successful run and no non-error answer. A new rule counts from its creation, so it never reports last week.
- **Run budget at X percent** of this month's allowance, once a month.

A rule fires once and says so when it clears, at least ten minutes later, so it cannot flap. Each change is an event and an [audit row](https://docs.qaldy.com/concepts/audit/). Delivery comes after and can fail without undoing the alert; each attempt is recorded (without the address or chat id). Email goes to owners and admins, at most 30 an hour per workspace. Telegram goes through the workspace's own bot connection, so the API never sees the bot token. Up to 20 rules per workspace, and a test send (six an hour) shows where an alert goes. Heartbeat alerts from [automations](https://docs.qaldy.com/connectors/webhooks/) land in the same history.

## The weekly digest

Every Monday at 06:00 UTC each workspace's owners and admins get the previous seven days: runs, failures, hours saved, the plan's list price (billing is [[Mock]], and the email says so), the busiest apps, and what needs a look: failing apps with their last error, apps that ran last week and not this one, and open alerts. It is in the workspace's language (English, Russian or Kazakh). One digest per workspace per week; each recipient has their own signed unsubscribe link and a one-click `List-Unsubscribe` header. Admins can preview it and send a test to themselves from Alerts.

## The public status page

Turn it on in Alerts, under Public status page: pick the title and which apps it lists, then share its address. It shows one word for the whole workspace and one for each listed app, 14 days of run results and incidents. A page that is off, missing or private answers the same 404, so nobody can tell which. No session is needed to read it.

## Not built yet

- No per-workspace retention setting; the 7 and 14 days are fixed.
- Alert channels are email and one Telegram chat per rule. Slack and webhooks are not offered.
- The MCP server has no tool for logs and metrics yet; the API routes allow a read token.