Product

Monitoring

Stackap runs a set of health checks on the server and every project, sends an alert when one fails, and records the load time of every project's requests.

What it does

These checks run continuously: host CPU, memory and disk, the Postgres server, running containers, database backups, repository backups, TLS certificates, recent deployments, and scheduled jobs. Each reports ok, warn or fail with a one-line detail, and the platform summarizes them as one overall state.

When a check fails, an alert goes to a Telegram chat, and it repeats every six hours until the check is ok again, so a missed message is not a missed problem. The platform operator can read the current alerts through the API.

Separately, every project gets load-time metrics. The web server in front of the apps writes an access log, which is turned into per-project request counts and a latency histogram, from which the median and slower percentiles are estimated. Ranges of one hour, 24 hours and seven days are available, and each deployment gets its own summary so you can see whether a release made things slower.

How it works

• The deployments check reports a failed build with the note that the previous deployment keeps serving.
• The backups check goes red if any database has no recent, verified backup, and it includes the control plane's own database.
• The certificates check reads the certificates actually served and warns as they approach expiry.
• cron warns when some jobs are flaky and fails when some are down.

Metrics are bucketed finely at the low end on purpose, because a fast app answers in a few milliseconds and coarse buckets made a fast app look slower than it was. Percentiles are estimates read from the histogram, not exact values.

In practice

$ stackap status        # platform operators only
GET /v1/projects/my-app/metrics?range=24h

Early-access scope

• The monitor runs on the same server it watches. A whole-server outage cannot alert you, so pair it with an outside uptime checker. No external probe is built in.
• The host-wide status command and the alert list are for the platform operator only, because they name every tenant's projects.
• Alerts go to one Telegram chat. Email and other channels are not built.
• There are no custom metrics, no error tracking and no traces.
• Latency figures are estimated from a histogram, and they describe requests as seen at the server, not what a visitor far away experiences.

Questions

Last updated 2026-10-03.