Logs, alerts and the weekly digest

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

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. 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 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.