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.
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.
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.
| 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.
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 sourcesAn uptime check, a PromQL query or a log query, each with a severity, a runbook and a route.
- Describe it in wordsThe assistant drafts the query; you see it, edit it and run it read-only before anything is saved.
- Backtest firstSeven days of your data show how often the policy would have fired.
- One notifierAlerts are deduplicated and grouped into incidents, routed by label and severity, and held by silences and maintenance windows.
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/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.
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_idand 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.
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 priceFrazer 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.