Monitor

An always-on evaluation rule for production sessions

What is a Monitor?

A Monitor is an always-on evaluation rule for a product’s production sessions. The Monitor is the rule; the production sessions are the data it watches. Once you create a Monitor, Galtea keeps scoring a sampled fraction of that product’s production sessions on its own, with no run to trigger by hand.

Each Monitor watches one Product. You can narrow it to a single Version, or leave the version unset to watch every version of the product. For each production session it decides to score, the Monitor evaluates the session with the metric families it scores and records the result. You choose those families directly, through Specifications, or both.

A Monitor scores production sessions (sessions logged with is_production=True). It does not run your test suites and does not create new sessions. See Monitor Production Responses for how production sessions are logged. Production sessions can also be created by ingesting OpenTelemetry traces; see Monitor Real User Traffic via OpenTelemetry. Ingested spans that name a test case create a non-production session instead, so no Monitor scores it.

Finding monitors in the dashboard

In the dashboard, open a product, switch to Production view mode, then pick Monitors in the sidebar, under Product. That page lists every monitor for the product. The entry appears only in Production view mode, because monitors watch production sessions; use the Development/Production switch in the sidebar if you do not see it.

From there you can create a monitor, open one to see its results, and edit, pause, resume, or delete it. Each row shows the monitor’s status, its recent score, its sampling rate, and its credit spend for the month.

Seeing production scores across the whole product

A monitor’s own page shows the results of that one monitor. To see the trend across every production evaluation of the product, open the product’s Analytics section in Production view mode. It shows an evaluation scores over time chart: the average score per day across all production evaluations that match your current filters.

The chart is only in Production view mode, because it is a production-monitoring view. One Group by switch at the top of the Analytics page sets how the score charts group their scores: by specification (the default: one line per specification, built from the metrics linked to it) or by metric (one line per metric). It drives this chart, the selected version’s score rings, and the version comparison radar. Your choice is remembered, so the page opens the same way next time. When your metrics have evaluations but none of your specifications does, the page opens grouped by metric instead, because grouping by specification would show nothing there. Development and Production decide this separately, because they hold different evaluations. You can still switch to specification by hand. Every chart shows only the grouping you picked: if nothing has scores under that grouping, the chart says so instead of showing the other grouping’s data. The chart follows the same filters as the rest of the page, so changing the version, test, metric, specification, language, or time frame updates it too. To change a filter, open Filters and select its row. The Specifications filter shows only when you group by specification. Picking specifications narrows every chart to the metrics they link, and narrows the Metrics filter to those same metrics. It aggregates every matching production evaluation, including ones you triggered by hand, so it is a product-wide trend, not one monitor’s view.

Metric families follow revisions automatically

A Monitor binds metric families, not specific metric revisions. A metric family is every revision of a metric that shares the same family key (metric.metric_group_id in the SDK). When you revise a metric, the Monitor picks up the new revision automatically. You do not edit the Monitor.

This is why metric_group_ids takes family keys, not metric IDs. Read the family key off any metric in the family:

metric = galtea.metrics.get(metric_id="your-metric-id")
family_key = metric.metric_group_id

For each family, the Monitor scores one revision per session: the newest revision that is not legacy. If every revision is legacy, the Monitor scores the newest one that is not disabled, so a legacy revision keeps scoring until it is disabled. A revision stays the scored one when its evaluator model is retired or unavailable: its sessions get a SKIPPED evaluation with the reason, and a Monitor never switches to an older revision for them. An optimized revision is never scored until you choose Apply optimization: while the optimization runs, while it waits for your review, and after you choose Keep original, the Monitor keeps scoring the original revision. When every revision is disabled, each sampled session gets a final SKIPPED evaluation that names the metric as disabled. Deleting the revision the Monitor scores stops it scoring that family: it never goes back to an older revision.

A self-hosted metric family cannot be bound to a Monitor. A Monitor scores production sessions with no caller involved, and a self-hosted metric’s score always comes from the caller, so there is no score for the Monitor to record. The API answers 400 Bad Request when a create binds one, or when an update adds one; a family the Monitor already binds can still be resent without effect. In the SDK, galtea.monitors.create then returns None, and galtea.monitors.update raises the error.

A Self-Hosted family a Monitor already binds scores nothing: every session gets a final SKIPPED evaluation instead. A Human Evaluation family is checked the same way as any other metric (missing data or a disabled metric still SKIPs); once those checks pass, it waits PENDING_HUMAN for a reviewer, the same as on any other evaluation path.

Binding Specifications

A Specification states one requirement of your product and links the metrics that measure it. A Monitor can bind one or more Specifications of its product instead of, or together with, metric families. In the dashboard, pick them on the Specifications tab of the monitor form. In the SDK, the CLI, or the API, pass specification_ids.

• Union rule. The Monitor scores the metric families you picked plus the families its bound Specifications link. A family that appears twice is scored once. This is the same rule as POST /evaluations. You need at least one source, and the Monitor must have at least one family left to score. The API checks this only on create and on an update that changes the scope. A Monitor can end up with nothing to score later, for example when a bound Specification loses its last metric or is deleted. Sessions that close while it has nothing to score are never scored, and no SKIPPED evaluation is recorded for them. Scoring starts again with the sessions that close after a metric is linked again.
• It follows the Specification. When you link or unlink a metric on a bound Specification, the Monitor scores the new set from its next scan. Scores already recorded do not change.
• Policy and Capability only. An Inability Specification cannot be bound, because it has no metrics to score. A Specification of another product cannot be bound either. While a monitor binds a Specification, you cannot change its type to Inability.
• Some metrics are left out. A bound Specification brings a family only when the Monitor can score it. It leaves out a family whose newest revision is Self-Hosted, a family that cannot score production sessions, and a Classifier (Jev) family when classifier metrics are off on the deployment. The Monitor skips these without a SKIPPED evaluation. A family you pick directly is never left out this way.
• scored_metric_group_ids lists the families the Monitor scores now, from both sources. metric_group_ids keeps only the picked ones. specification_ids_by_metric_group_id names the bound Specifications behind each family they bring.

Deleting a Specification removes its link to the Monitor and deletes the alert rules on it. Alert rules, results and charts use the scored families, so they follow the bound Specifications too.

Sampling

sampling_percentage sets the fraction of production sessions the Monitor scores, from just above 0 up to 100. It defaults to 10 (10%). Sampling keeps monitoring affordable on high-traffic products: you get a representative signal without scoring every single session.

Changing sampling_percentage only affects sessions that close after the change. Raising it does not go back and score older sessions that were already skipped.

When a session gets scored

A Monitor scores a production session once the session is closed. A session closes either when you explicitly finish it, or when the product’s auto-close setting closes it after a period of inactivity. A closed session with no turns is treated as fully decided and never scored: there is nothing to send for evaluation, so no row is written for it. Sessions that end with an error are not scored. There is no per-Monitor inactivity setting: closing is decided by the session’s own state, so every Monitor on a product agrees on when a session is ready.

This depends on the product’s Auto Close Scope. When that scope excludes production (None or Development), open production sessions never close on inactivity, so the Monitor scores only the production sessions you explicitly finish.

A closed session can still gain a turn. When it does, the session reopens and the Monitor scores it again once it closes for good. The earlier scores move to the Outdated status, so they drop out of charts and averages while staying readable. The product’s Closed Session Inference Creation Policy controls this.

Credit cap

monthly_credit_cap is an optional ceiling on how many credits the Monitor spends per month:

• None (default) means the Monitor is uncapped. It scores sampled sessions until the organization runs out of credits.
• A positive number caps monthly spend. Only the “greater than zero” rule is enforced. The cap may be larger than the organization’s monthly credit allocation; the effective budget is min(organization balance, cap). So the cap protects a single Monitor’s spend, and the organization balance is always the hard limit.

Status

A Monitor has a status that tells you whether it is scoring and, if not, why. This makes the reasons a Monitor stopped visible instead of silent:

• ACTIVE — the Monitor is scoring sampled production sessions. New Monitors start here.
• PAUSED — a user paused the Monitor. It scores nothing until resumed. Sessions that close while it is paused are skipped for good. After a resume, the Monitor only scores sessions that close from that point on.
• CAPPED — the monthly credit cap was reached. Sessions that close while it is capped are skipped for good, like PAUSED. Scoring resumes next month, or sooner if you raise the cap.
• NO_CREDITS — the organization ran out of credits. Sessions that close in the meantime are skipped for good. Scoring resumes when credits are available.
• FAILING — reserved for a Monitor that keeps failing to score sessions. The system does not currently set it automatically.

Pause and resume a Monitor from its row menu, from its page in the dashboard, with galtea.monitors.pause and galtea.monitors.resume, with galtea monitors pause and galtea monitors resume, or with POST /monitors/{id}/pause and POST /monitors/{id}/resume. Both work from any status, and repeating one changes nothing. If a resumed Monitor is still capped or out of credits, the next scan sets CAPPED or NO_CREDITS again.

Setting status to ACTIVE or PAUSED through an update still works. You can set only those two values: CAPPED and NO_CREDITS are set by the system, FAILING is reserved, and the API rejects all three if you try to set them yourself.

Alert rules

An alert rule describes when a monitor should warn your team about one Specification or one metric within a time window. A rule is one of two types: too many badly scored sessions, or too many sessions that got no score (see Rule types). Open the monitor and pick the Alerts tab to add, edit, or delete its rules. Rules go on a monitor that already exists; the creation form has no alert fields.

• Alert when: “Sessions score badly” or “Sessions get no score”. This sets the rule type (see Rule types). You cannot change it when you edit the rule.
• Watches: what the rule watches. The field has two tabs: Specifications and Metrics. Pick one Specification the monitor binds, or one metric the monitor scores. Add one rule per target to watch several. The form opens on Specifications when the monitor binds a Specification that brings a scored metric. When the monitor binds no Specification, that tab is disabled and says “This monitor binds no Specification”. You cannot change the tab when you edit the rule. Through the API, send specificationId in place of metricGroupId, never both.
• Window: 15 minutes, 1 hour, 6 hours, or 24 hours.
• Bad metric score: 0 to 1. A session is bad when its metric score is at or below it. On the Specifications tab, the form labels this field “A session is bad when any of its metrics scores at or below”. The form shows this field only for “Sessions score badly”.
• Threshold: for “Sessions score badly”, a whole number of 1 or more: the number of bad sessions within the window that the rule watches for. For “Sessions get no score”, the label is Threshold (%): a percent above 0 and at most 100, with a default of 20.
• Recipients: 0 to 20 email addresses. The form starts with your own. Stored in lowercase, and a repeated address is kept once.
• Webhook URL: optional, one per rule. Galtea sends a signed POST to it when an alert opens or recovers (see Webhooks). A rule needs at least one email address or a webhook URL. For a second webhook, add a second rule.

A new rule starts with “Sessions score badly”, a 1 hour window, a bad metric score of 0.5, and a threshold of 10, and the list shows it as “10 or more sessions with a metric score of 0.5 or lower within 1 hour”. A “Sessions get no score” rule shows as a percent of evaluated sessions with no score within the window.

While a “Sessions get no score” rule has fewer evaluated sessions in its window than it needs, the list and the rule page show a line next to its status, for example “Waiting for data: 3 evaluated sessions in the last hour (minimum 5)”. Hover the line to see why. The line is not shown for a paused rule. The dashboard says “evaluated sessions” for what the API calls settled sessions.

The list has a Watches column that shows the Specification or the metric of each rule. A metric that a Specification brings shows that Specification beside it. A warning icon marks a target the monitor no longer scores. Filter the rules by what they watch, by status, or by creation date. Click a rule to open its page. Its header shows the status, a Pause or Resume button, and a menu to edit or delete the rule. The Overview tab lists its condition, recipients, webhook host, and recent activity. The Alerts tab shows the alert history of that rule only. A rule you add opens on its own page.

Pause a rule from its row menu to stop it without losing its settings. A paused rule is not checked, so it opens no alert and sends no email or webhook. If it has an open alert, pausing closes it without a recovery email or webhook. The Status column then shows Paused; hover it to see when. Resume the rule from the same menu: the next check evaluates it from scratch, so a window still over the threshold opens a new alert and notifies its recipients and its webhook. Through the API, call POST /monitors/{monitorId}/alert-rules/{alertRuleId}/pause and /resume.

A rule can use any family the monitor scores, including one that a bound Specification brings. Removing a metric family from the monitor, or unbinding the Specification that brought it, deletes the alert rules on that family unless another source still brings it. When a bound Specification stops linking a metric, the rules on its family stay but open no alert, and the dashboard marks them as not scored. An alert such a rule already opened closes when the window recovers. You can still edit such a rule: it keeps its metric, and the form warns that the rule opens no new alert until you add the metric back to the monitor or pick another metric. Unbinding a Specification from the monitor, or deleting the Specification, deletes the alert rules on it. Deleting the monitor deletes its alert rules.

Rules on a Specification

A rule on a Specification counts sessions, not metrics. A session fails the Specification when any metric the Specification brings into the monitor fails it. For a “Sessions score badly” rule, that means a score at or below the bad metric score. For a “Sessions get no score” rule, that means the evaluation settled with no score. A session that fails two metrics counts once. The rule compares that count, or that rate, with its threshold, the same way a metric rule does.

The rule page shows the metrics the Specification brings now, and a line that says when a session counts. The rule covers every metric the Specification brings at check time. When you link a metric to the Specification, the next check watches it, and you do not edit the rule. When you add the rule, the Specification must bring at least one metric the monitor scores. If it brings none later, the rule stays and opens no new alert. You can still edit it: it keeps its Specification, and the form warns that the rule opens no new alert until you link a metric the monitor scores to the Specification or pick another Specification. An alert that is already open is still checked on the metrics it measured when it opened, so it can recover.

Viewing rules needs read access to the monitor; adding, editing, pausing, resuming, or deleting them needs the permission to edit it.

Rule types

Through the API, a rule has a required type. In the dashboard, the Alert when choice sets it: “Sessions score badly” is BAD_SESSION_COUNT and “Sessions get no score” is NO_SCORE_RATE. The type cannot change after you create the rule.

• BAD_SESSION_COUNT: the threshold is a whole number of bad sessions, as described above, and badSessionScore is required.
• NO_SCORE_RATE: alerts when evaluations stop producing scores, for any reason, for example because the judge model is no longer available. The threshold is a percent, greater than 0 and at most 100, and badSessionScore must be null. The rule opens an alert when the percent of settled sessions in the window that produced no score meets the threshold. An evaluation is settled when it has a score or has the status FAILED or SKIPPED. Every evaluation that settles without a score counts as “no score”: FAILED, and every SKIPPED cause, including a classifier “Does not apply” answer and max_tokens_exceeded. A regular no-score of any cause needs a person to look. So on a classifier family where “Does not apply” is normal, set the threshold above that normal rate. A session counts once, by its latest settled evaluation in the window. Long-input classifier verdicts are not counted. The rule opens or closes nothing until the window holds at least 5 settled sessions. When you list a monitor’s rules or read one rule, each NO_SCORE_RATE rule carries readiness: the settled sessions in its current window, the 5 it needs, and isEvaluating, which is false while the window holds fewer or while the rule is paused. readiness is also null when the count cannot be read right now. BAD_SESSION_COUNT rules carry null. The alert closes once the rate drops to the threshold minus its square root, rounded down and never below 0: a 10% threshold closes at 6%.

AVERAGE_SCORE rules are not accepted yet.

An alert’s observation in the API holds what the check saw, and its type is the rule type. For a NO_SCORE_RATE alert it holds noScoreRate, noScoreSessionCount, and settledSessionCount, and the alert email states the rate and the session counts.

Alerts

A rule opens an alert when its threshold is reached. The alert closes once its value (the bad session count, or the no-score rate) falls to its clear value or lower (the threshold minus its square root, rounded down and never below 0), when its rule is deleted or paused, or when what the rule watches (its metric or its Specification), its bad metric score, or its window changes. Linking or unlinking a metric on a Specification does not close an open alert. The Alerts tab shows alerts next to the rules:

• Status: “Paused” when the rule is paused, “Open” with the time it opened when the rule has an open alert, “Waiting” when a no-score rule does not have enough evaluated sessions yet, or “OK”.
• Alerts · 30 days: how many alerts were open at some point in the last 30 days, and when the newest one opened.
• Alert history: a timeline with one line per rule and a bar for each time an alert was open, above a table of the alerts. Filter both by state and by rule, one or more of each. Filter by time range too: the last hour, 6 hours, 12 hours, 24 hours, 7 days, 30 days, 90 days, year, or 2 years, or a period you pick in the calendar. A range from that list moves with the clock, and hovering its name shows the dates it covers.

Select an alert to open its page. It shows what the check saw when the alert opened: the value the rule compared with its threshold (the bad session count, or the no-score rate), the number of sessions it came from, the threshold, the window, the sampling rate, and, for an alert on a metric, the metric revision. The API returns the metric revision only for an alert on a metric. For a BAD_SESSION_COUNT alert the sessions are the scored sessions in the window. For a NO_SCORE_RATE alert they are the settled sessions, and the alert opens or closes only with at least 5 of them. These values do not change later, even if a session is scored again. For a NO_SCORE_RATE alert the page shows the no-score rate, the threshold, and the close value as percents. The page also lists the monitor’s evaluations of the sessions the alert stored when it opened, up to 200 sessions per alert. For a BAD_SESSION_COUNT alert these are the bad sessions, and you can see each score. For a NO_SCORE_RATE alert these are the sessions with no score; check the status column to see why each one got no score.

An alert on a Specification names the Specification and the metrics that caused it. Its alert page has a Specification row with a link to it. If you deleted the Specification, the row shows its stored name. The page also has a Metrics that caused it card, which lists each metric that failed at least one session, with its count and a bar. Because one session can fail several metrics, the counts can add up to more than the number of sessions. The alert stores every metric the check measured when it opened, up to 50, with the sessions it counted and the sessions that failed for each metric. The metrics with at least one failed session are the causes. A session that failed several metrics counts in each of them and once in the value of the alert. The API returns these metrics in families, and returns the Specification name in specificationName, also after you delete the Specification. The email sent when the alert opens names the Specification and lists up to five causes with their session counts. The recovery email names the Specification only. The measured metrics do not change when you link or unlink metrics later.

Webhooks

A webhook sends the alert to your own system, or to a chat channel, as a signed POST with a JSON body. It covers the same two events as the email: monitor_alert.opened and monitor_alert.recovered. A rule with only a webhook URL and no email address works.

Set the URL in the Webhook URL field of the rule form, or send webhookUrl through the API or the CLI. The URL must use https, can have at most 2048 characters, and cannot hold a user name or password. A deployment can allow http. The URL is write-only: Galtea never returns it. The API and the dashboard show only its host and port, for example hooks.slack.com or hooks.example.com:8443. The port shows only when it is not the default. To change the URL, send a new one. To remove it, send null. In the dashboard, turn on Remove the webhook in the edit form. An empty URL field keeps the saved URL.

Galtea checks the host when it saves the rule. An IP address or localhost in a private or reserved range is refused. A host name is checked again on every delivery. A name that points to a private network is refused at delivery, not at save, and Galtea does not retry it. Galtea does not follow redirects.

Request. Galtea sends one POST with Content-Type: application/json and these headers:

• Galtea-Signature: t=<unix seconds>,v1=<hex signature>. See Verify a webhook.
• Galtea-Event: monitor_alert.opened or monitor_alert.recovered.
• Galtea-Webhook-Id: <alert id>.opened or <alert id>.recovered. It is the same value on every retry, so your receiver can use it to ignore a repeat.
• User-Agent: Galtea-Webhooks/1.

Body. The same fields as the alert email. A field that does not apply to the event is left out.

{
  "id": "7c1f0c3e.opened",
  "event": "monitor_alert.opened",
  "occurredAt": "2026-10-13T09:00:00.000Z",
  "text": "**Alert opened** on monitor [Support bot](https://platform.galtea.ai/product/p1/monitor/m1) ...",
  "monitor": { "id": "m1", "name": "Support bot", "url": "https://platform.galtea.ai/product/p1/monitor/m1" },
  "alert": {
    "id": "7c1f0c3e",
    "url": "https://platform.galtea.ai/product/p1/monitor/m1/alert/7c1f0c3e",
    "type": "BAD_SESSION_COUNT",
    "metric": "Helpfulness",
    "revision": null,
    "window": "SIX_HOURS",
    "windowEnd": "2026-10-13T09:00:00.000Z",
    "threshold": 3,
    "observedValue": 4,
    "sampleSize": 18,
    "badSessionScore": 0.4,
    "samplingPercentage": 10,
    "sessionCount": 4,
    "sessions": [{ "id": "s1", "url": "https://platform.galtea.ai/product/p1/version/v1/session/s1" }]
  }
}

• id, event, occurredAt: the event id (the same as Galtea-Webhook-Id), its name, and when it happened. For monitor_alert.opened this is the end of the window, and for monitor_alert.recovered it is the close time.
• text: the message in Markdown, as the chat tools below show it.
• monitor: the id, name and dashboard url of the monitor.
• alert.id, url, type, metric, window, threshold: the alert, its dashboard page, its rule type, the metric family name, the window (FIFTEEN_MINUTES, ONE_HOUR, SIX_HOURS or TWENTY_FOUR_HOURS), and the threshold.
• alert.observedValue and alert.sampleSize: what the check saw when the alert opened. For BAD_SESSION_COUNT they are the bad session count and the scored session count. For NO_SCORE_RATE they are the no-score rate in percent and the settled session count. badSessionScore is sent for BAD_SESSION_COUNT only.
• On a rule that watches a Specification: metric is null, and specification names the Specification. An opened alert also sends causes, up to five metricName and matchCount pairs, the strongest first.
• Opened only: revision (the metric revision, null for the family head), windowEnd, samplingPercentage, sessionCount (the sessions behind the alert) and sessions (up to 25 session id and url pairs).
• Recovered only: openedAt and closedAt.

Respond with a 2xx status. Any other status counts as a failure. Galtea waits 5 seconds for the answer.

Retries. Galtea tries up to 6 times: at once, then about 10, 30, 70, 150 and 310 seconds after the first try. A timeout, a network error, and a 408, 429 or 5xx status are tried again. Every other 4xx status, a redirect, a refused destination, and an unexpected error while Galtea sends the request stop the delivery at once. A delivery that fails after the last try is dropped, and the dashboard does not show it. A retry can reach your receiver twice when its answer is lost, so use Galtea-Webhook-Id to ignore a repeat. Delivery order is not guaranteed: a retried event can arrive after a later one, so order events by occurredAt. A webhook failure never delays or repeats the alert email. When Galtea cannot queue a delivery at all, that alert is not posted to your webhook.

Verify a webhook

Checking the signature is optional. It proves that Galtea sent the request. Each rule has one secret that starts with whsec_. Galtea shows it once:

• In the dashboard, tick Show the signing secret after saving under the URL field. The box starts unticked. After the save, a dialog shows the secret. A new rule opens on its own page, and the dialog appears there. Copy the secret, tick the confirmation box, then click Done. On a rule that already has a URL, the box reads Show a new signing secret after saving and replaces the current secret. A secret is created with the first URL and kept when you replace or remove the URL. You can also use Regenerate signing secret in the rule’s menu on a rule that has a webhook URL. The dashboard asks you to confirm before it replaces the secret.
• Through the API or the CLI, create or update the rule, then call POST /monitors/{monitorId}/alert-rules/{alertRuleId}/regenerate-webhook-secret or run galtea monitors regenerate-alert-rule-webhook-secret. This is the only way to read a secret, and it needs a rule with a URL. Create and update never return it. The dashboard menu entry Regenerate signing secret does the same.

A new secret replaces the old one, which stops working at once. Store the secret with your endpoint’s configuration.

To verify a request:

1. Read the t and v1 values of the Galtea-Signature header.
2. Reject the request when t is more than 5 minutes from your clock.
3. Compute the HMAC-SHA256 of <t>.<raw body> with the secret, as hex. Use the raw bytes you received, not a parsed and re-encoded body.
4. Compare it with v1 in constant time.

Node.js

import { createHmac, timingSafeEqual } from "node:crypto";

// rawBody is the request body exactly as received (a Buffer or a string).
export function verifyGalteaSignature(rawBody, header, secret, toleranceSeconds = 300) {
  if (!header) return false;
  const parts = Object.fromEntries(header.split(",").map((part) => part.split("=")));
  const timestamp = Number(parts.t);
  if (!Number.isFinite(timestamp)) return false;
  if (Math.abs(Date.now() / 1000 - timestamp) > toleranceSeconds) return false;

  const expected = createHmac("sha256", secret).update(`${timestamp}.`).update(rawBody).digest();
  const received = Buffer.from(parts.v1 ?? "", "hex");
  return received.length === expected.length && timingSafeEqual(received, expected);
}

Slack and self-hosted chat

• Slack. Create an incoming webhook and paste its URL. A URL on hooks.slack.com or hooks.slack-gov.com gets a Slack message instead of the JSON body above: a bold title, the sentence, a link to the alert, and up to 10 session links. When an alert has more sessions, the message links to the monitor’s sessions tab.
• Mattermost and Rocket.Chat. Paste the URL of an incoming webhook. Both read the text property of the JSON body and show it as Markdown, with the same message and links.

SDK Integration

The SDK lets you create, list, retrieve, update, pause, resume, and delete monitors. See the Monitor Service API documentation for more details.

Monitor Service

Manage monitors programmatically

Monitor Properties

id · string

Unique identifier of the monitor.

name · string · required

Name of the monitor.

product_id · string · required

The ID of the product whose production sessions this monitor scores.

version_id · string

The ID of a single version to watch. When unset, the monitor watches every version of the product. Changing it only affects sessions that close after the change; sessions already skipped under the old value are not picked up.

metric_group_ids · list[string]

The metric family IDs (metric.metric_group_id) picked directly. Can be empty when the monitor binds a Specification. The monitor binds the family, not a specific revision, so revising a metric is picked up automatically.

specification_ids · list[string]

The IDs of the Policy and Capability Specifications the monitor binds. Can be empty when the monitor picks families.

scored_metric_group_ids · list[string]

The families the monitor scores now: the picked families plus the families its bound Specifications link, minus the Specification families it cannot score. Read-only.

specification_ids_by_metric_group_id · dict[string, list[string]]

For each family a bound Specification brings, the IDs of the bound Specifications that bring it. Read-only.

sampling_percentage · number · default: "10"

Percentage of production sessions to score, from just above 0 up to 100. Defaults to 10 (10%).

monthly_credit_cap · int

Maximum credits to spend per month. Must be positive when set. None means uncapped. The effective budget is min(organization balance, cap), so a cap may exceed the monthly allocation.

status · Enum

The lifecycle status of the monitor. Possible values: ACTIVE, PAUSED, CAPPED, NO_CREDITS, FAILING. Only ACTIVE and PAUSED can be set by a user; the rest are system-set.

created_at · string

Timestamp of when the monitor was created (ISO 8601 format).

Related

Concepts overview

How Galtea’s concepts connect — diagram + per-entity quick reference.

Product

A functionality or service being evaluated

Metric

Ways to evaluate and score product performance