--- title: "Frazer Monitoring: metrics, logs, uptime checks and incidents · Frazer" description: "Metrics and logs from every cluster's first minute, built-in dashboards for every project, uptime checks from three locations, alert policies with a 7-day backtest, and incidents that name the last deploy." url: https://frazer.ai/monitoring index: https://frazer.ai/llms.txt tokens: 2953 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Frazer Monitoring: metrics, logs, uptime checks and incidents · Frazer **Frazer Monitoring** frazer.ai # Metrics, logs, checks and incidents. From the first minute of every cluster. Every cluster ships metrics and logs to a monitoring cell that Frazer runs, and every project gets its dashboards already built. Uptime checks probe from three locations, alert policies page the people you route them to, and an incident opens with a read-only triage that names the last deploy. [Add an uptime check](https://frazer.ai/start?product=monitoring) [Read the docs](https://frazer.ai/docs) *Incident 142 in the demo organization Acme: api.acme.example served more than 5 % errors for 23 minutes. The read-only AI triage names the likely cause, the rollout of checkout-api version 1.44.0 fourteen minutes before the alert, and suggests a rollback that a person approved. The timeline lists each step from trigger to resolve, and who did it for whom.* An incident in Frazer Monitoring: the AI triage beside the timeline of who did what product UI, demo organization 01 · How it works Fig. 1 ## Collected everywhere. Read one project at a time. Agents in every cluster ship metrics and logs, outbound only, to a monitoring cell in your Frazer region. Each project is its own tenant, so a query, a dashboard or an alert reads that project’s data and nothing else. Policies turn the data into alerts, and one notifier turns alerts into incidents. **Fig. 1** From agents and probes to dashboards, alerts and incidents 02 · Uptime checks ## Down means two of three. Not one flaky probe. Where they run Three Frazer locations on different providers, and private probes inside your clusters or on any network, over one outbound stream. When a check is down When at least 2 locations fail in one interval. A location whose own canaries fail is set aside, and Frazer is paged instead of you. IPv4 and IPv6 Probed one family at a time by default, so a broken AAAA record shows as IPv6 down, not up. Tokens in headers Kept in the secrets store and injected at the probe; never shown again, to people or to AI tools. Uptime check types and what each one checks | Check | What it checks | | --- | --- | | HTTP(S) | Method, headers, body, expected status, body text or JSON path, maximum latency, up to 5 redirects | | TCP | Connect, with optional TLS | | TLS expiry | Days left, chain validity, hostname match | | Heartbeat | A ping URL for cron jobs, with start and fail signals; a period and grace, or a cron schedule | | DNS | Record type, expected values, resolver | | ICMP | Ping, with a packet-loss threshold | | gRPC health | The standard grpc.health.v1 service | Results land in the project’s own metrics and logs, one log line per run. 03 · Alert policies Fig. 2 ## Test an alert before it pages. Seven days of backtest, then save. Write a policy on a check, a metrics query or a log query, or describe it in words and edit the query the assistant drafts. Frazer generates the rules from it; you never write rule files by hand. - **Three sources** An uptime check, a PromQL query or a log query, each with a severity, a runbook and a route. - **Describe it in words** The assistant drafts the query; you see it, edit it and run it read-only before anything is saved. - **Backtest first** Seven days of your data show how often the policy would have fired. - **One notifier** Alerts are deduplicated and grouped into incidents, routed by label and severity, and held by silences and maintenance windows. *The alert policy HighErrorRate in the demo organization Acme: described in words, turned into a PromQL query that runs read-only, and backtested over the last 7 days, where it would have fired twice. Beside it, its routing to Slack, PagerDuty and email, a silence and a maintenance window, and four verified channels.* **Fig. 2** An alert policy with its backtest, routing and channels product UI, demo organization 04 · From the terminal and from Git ## Query from the terminal. Keep the rules in Git. `frazer logs` and `frazer monitoring metrics` read the monitoring cell, so they work without access to the cluster. Alerts come from three places, all routed by the same notifier. Frazer’s defaults Node and disk pressure, certificate expiry, backup age, GitOps out of sync, crash loops. Mute them per project; they cannot be deleted. Rules in Git PrometheusRule resources in your environment repository, applied by Frazer GitOps like the rest of the app. Alert policies From the console, the API, the CLI or an MCP client, each with a plan and an audit entry. ``` $ frazer logs --cluster acme-production-1 \ 'namespace:acme level:(error OR warn)' --since 15m 14:02:11 error notifications upstream timeout calling orders-db pooler 14:02:11 error checkout-api POST /notifications.v1.Messages/Send → 503 14:02:10 warn notifications pooler: client waiting 1.4 s 14:02:10 warn checkout-api circuit half-open for notifications # Reads the monitoring cell: no access to the cluster needed ``` ``` # envs/production/alerts/acme.yaml, applied by Frazer GitOps apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: acme spec: groups: - name: notifications rules: - alert: Notifications5xxHigh expr: | sum(rate(http_server_request_duration_seconds_count{ http_response_status_code=~"5..", service="notifications"}[5m])) / sum(rate(http_server_request_duration_seconds_count{ service="notifications"}[5m])) > 0.01 for: 5m labels: severity: critical ``` ``` # A dashboard you keep as a view definition, written through the dashboards API with an audit entry $ frazer monitoring dashboards apply -f dash.yaml # Or keep a repository folder in sync, such as acme/platform-envs dashboards/ ``` 05 · What you get ## Everything you watch with. Nothing you have to install. - ### Metrics Frazer Monitoring’s metrics store with PromQL, kept 30 days by default. No Prometheus server to run. - ### Logs Frazer Monitoring’s log store with facets, patterns, live tail and saved queries. Known token formats are dropped before storage. - ### Dashboards for every project Frazer’s own dashboards in the console and the app, built in for every product you use, and every panel’s query runs as its viewer. - ### Dashboards as code View definitions in a repository, synced both ways, `frazer monitoring dashboards apply`, the API or MCP. Dashboard JSON from other tools imports. - ### Incidents One incident per alert fingerprint, with a timeline, acknowledge and resolve, and a postmortem in Markdown. - ### Silences and maintenance Label matchers with a reason and an author; one-off or recurring windows per check or label. - ### Traces An OpenTelemetry collector per cluster, opt-in, with auto-instrumentation for Java, Node.js, Python and .NET. - ### Status pages Components from your checks, served as static pages from a CDN, so they stay up when the control plane does not. 06 · Controls ## Who sees what, and who is paged. With the defaults stated. ### Who may do what Viewer Reads metrics, logs, dashboards and incidents. Responder Acknowledges and resolves incidents, sets silences and maintenance windows. Changes no resources. Developer Creates checks, policies and dashboards. Admin, Owner Everything in Monitoring. Only an Owner can turn on public dashboards for the organization. Agents Read through the monitoring, logs, metrics and incidents tools. A fix they suggest is a plan a person approves. ### What is logged - Every create, change and delete of a check, policy, channel or silence: an API call with `validate_only`, `request_id` and an audit entry. - Who created each policy, and whether an agent drafted it. - Each silence with its start, end, reason and author. - New dashboards and copies, as audited Live actions. - Each incident’s timeline: alerts, notifications, acknowledgments, comments and AI notes. ### At the cap - Above the included allowance, monitoring is sampled down to it. **Alerts are never dropped.** - Ingest and cardinality limits per project; the agent drops high-cardinality labels before they are stored. - AI triage stops after 60 seconds and a fixed number of tool calls. - Public dashboards are off by default. - Every channel is verified before use and has a rate limit. 07 · Pricing ## Included with every server. Pay only above the allowance. Every server you bring adds to an allowance of metric series, logs and uptime checks, pooled across the billing account. Above it you pay per GB of logs and per 1,000 active series. [See every price](https://frazer.ai/pricing#lines) Your servers 50,000 series, 50 GB logs (kept 30 days) and 20 uptime checks per server included Above the allowance Logs $0.20 / GB · metrics $1 per 1,000 series · checks $1 per check / month Pooled Across every server on the billing account; DNS health checks count as uptime checks Questions ## Frazer Monitoring, answered. Do I run a metrics server or dashboards myself? No. Every cluster starts with Frazer Monitoring’s metrics agent and log collector, and Frazer runs the storage in a monitoring cell in your region. The agent reads `ServiceMonitor`, `PodMonitor` and `PrometheusRule`, so third-party Helm charts work unchanged. The dashboards run once per organization, with a space per project and your Frazer sign-in. Can one project read another project’s data? No. Each project is its own tenant, and every read goes through a proxy that checks your Frazer token and pins the tenant: in the console, in the dashboards and in the queries the assistant writes. Organization admins get an All projects view of their own projects. How does an uptime check decide a site is down? Each location runs the check once per interval and retries once on failure. The check is down when at least 2 locations fail in the same interval; 1 of 3 shows as degraded and pages nobody. If a Frazer location loses its own connectivity, its results are set aside and Frazer is paged, not you. What does AI triage do, and can it change anything? When an incident opens, the assistant runs a read-only investigation, capped at 60 seconds and a fixed number of tool calls. It posts what fired, the blast radius, the changes of the last 2 hours from the audit log, unusual log patterns, and runbook steps with links to the evidence. It changes nothing by itself. A fix it suggests is a plan that a person approves, and log lines and HTTP bodies are treated as untrusted input. Can I keep dashboards and alert rules in Git? Yes. Keep your dashboards’ view definitions in a repository folder, synced both ways, or apply one with `frazer monitoring dashboards apply`. Alert rules can live in your environment repository as `PrometheusRule` resources. Built-in dashboards update with Frazer and are read-only; Save as copy makes one yours. Where do alerts go? To email, Slack, signed webhooks and PagerDuty, each verified before use and with a send-test button. Routes group alerts by label and severity and set a repeat interval. On-call schedules stay in PagerDuty, which Frazer bridges to. ## More in Operate and secure - [**Security Center** Posture, threats, evidence](https://frazer.ai/security) - [**Identity and access** Roles, SSO, audit](https://frazer.ai/iam) - [**Billing and budgets** Caps that pause](https://frazer.ai/billing) ## Watch every project. Get paged with the evidence attached. [Add an uptime check](https://frazer.ai/start?product=monitoring) [Read the docs](https://frazer.ai/docs)