An application can still be reachable while memory rises or its container repeatedly restarts. Impreza’s Metrics & alerts view brings recent measurements and alert evidence into the same account where you manage the app. An authorized AI assistant can read that evidence through MCP.
This is container monitoring. It does not collect application traces, request contents or business metrics, and it does not automatically repair or restart an app.
Check the agent and open the app
Use an app managed by a compatible Impreza Agent, version 0.6.17 or later. Update the agent explicitly after active operations finish; installing a newer MCP package does not update the server. Local MCP 0.39.0+ exposes the documented workflow.
Open My Apps, select the application and find Metrics & alerts under Advanced. API inspection requires read permission; changing alert rules requires deploy permission. Account and resource authorization remain in effect.
Read the recent measurements
Through MCP, call impreza_app_metrics with the deployment ID. The optional minutes window accepts 5-129600 (about 90 days) and defaults to 120. Inspect container state, restart count, CPU percentage, memory use and limit, and estimated volume bytes.
Recent reads show minute points for up to 24 hours. Minute measurements are kept for 48 hours; older closed hours are consolidated into hourly points retained for 90 days. A longer query combines hourly history with recent minute points, with each point marked by its resolution. Current agents report one CPU sample per minute, so that reading remains an instantaneous sample. The platform can calculate a sample-weighted bucket average when an agent supplies multiple samples. Docker volume usage is an estimate. Compare timestamps and resolution with when the symptom occurred, and use application logs for the events behind a spike.
Missing data means unknown. It is not proof that an app is healthy, idle or consuming zero resources. Check the agent and collection path before diagnosing an empty chart as an application outage.
On servers with the updated proxy, proxy_metrics also reports aggregate request counts by status class, latency percentiles, transferred bytes and Shield outcomes for a routed app. Minute detail is kept for 48 hours; this is not a visitor-level log or long-term request history. The Shield guide explains what the protection counters do and do not show.
Choose a rule for a specific symptom
The general app rules below cover runtime and backup conditions. Eligible features can add their own rules; standby alerts are described separately below.
| Rule | What to configure |
|---|---|
| down | Threshold 1 for the unavailable condition |
| restart_loop | A restart-count threshold |
| memory_pct | 1-100 percent of the configured memory limit |
| cpu_pct | CPU threshold from 1-10000; 100 represents one full core |
| agent_offline | Threshold 1 when the agent is offline |
| backup_failed | Threshold 1 when a backup has failed |
For the general rules above, choose a duration from 1 to 60 minutes. For example, the following impreza_set_alert_rule arguments create an enabled memory rule after you replace the deployment ID:
{
"deployment_id": "dpl_REPLACE_ME",
"metric": "memory_pct",
"threshold": 85,
"duration_minutes": 3,
"enabled": true
}
The example is a starting point, not a universal limit for every workload. Read existing rules first. Supply the existing rule ID when updating one, so you do not unintentionally create duplicate rules. CPU alerts are available; volume measurements do not imply a disk alert rule. agent_offline and backup_failed are evaluated by the platform’s minute check rather than an agent report.
Review alerts for a cold standby
For an eligible failover pair, the first verified sync creates enabled standby_stale and drill_failed rules on the primary app. Review them in My Apps → Advanced → Metrics & alerts. The first flags a scheduled sync that is at least 30 minutes overdue, with no drill running; the second flags the pair’s latest finished drill when it failed.
Without a drill policy there is no sync deadline, so the stale condition does not open. Neither condition opens while a drill or cutover runs; disabling failover clears open alerts and stops new ones. Inspect actual sync time, policy and drill results instead of treating silence as proof of readiness.
Disable a rule to keep it off. Deleting it allows recreation at the next verified sync. Existing alert lifecycle and webhook delivery apply; an alert does not authorize or execute failover, repair, traffic changes or DNS updates. Keep the reviewed failover procedure.
You can also review the pair’s open notices directly in the failover panel. The current REST and hosted MCP standby read include up to four open notices for that account and primary app, with the condition, UTC opening time and limited evidence such as the sync age or a known failure reason. A notice disappears from that view when its condition resolves. Use those details to choose the next check; they do not approve a repair or a traffic switch.
Resolved standby alerts become eligible for cleanup after 30 days. Open alerts and recent history are preserved, and bounded background cleanup can run later than that threshold. This is alert-history retention, not a policy for backup copies or a promise that every notification was delivered.
Use the standby alert reference for exact behavior and the REST API reference for current fields. A local MCP package may expose an older response schema; check its supported fields rather than assuming that updating the server also updates the connector.
Inspect alerts before deciding on a repair
Use impreza_list_alerts to read rules, open and resolved alerts, and their evidence. Compare the alert with current measurements and logs. A resolved alert records a condition change; it does not establish that every user-facing function works.
Review this app’s recent metrics and alerts. Explain the timestamps and evidence, then suggest the next read-only checks. Do not change rules or restart the app.
Use inspection and maintenance for the next diagnostic step. Keep an observation separate from authorization to perform a repair.
Share a native public status page
An eligible platform app can have an opt-in status page with its chosen public name, current availability and incident history. Configure an enabled external unreachable uptime rule first. Checks use public HTTPS on port 443 or an .onion address over Tor; without eligible measurements the page can show Not monitored yet instead of proving availability.
For a custom app, use My Apps → Advanced → Public status page. Catalog apps use the supported API or MCP flow. The hosted connector and local impreza-mcp 0.56.0 or later provide impreza_get_status_page and impreza_set_status_page, subject to access and feature availability. Publishing needs management permission; an app is not published merely because it has metrics.
Choose a neutral public name and review the shared page. It does not automatically disclose the app’s domain, server IP or account identifier, but anyone with its address can read the public fields. You can rename, rotate the address or withdraw the page. Follow public status pages for the coverage and publishing steps.
Review protection alongside app health
Agent 0.6.27 or later adds detailed Shield rule review and configurable protection for compatible routes. Aggregate WAF counts help investigate false positives; they do not identify individual visitors or prove an attack. Follow Impreza Shield to review challenges, request limits and temporary attack mode. These controls complement runtime metrics; they do not provide external uptime monitoring.
Decide whether notifications should leave the portal
Alerts are recorded in the portal even without an external notification destination. To notify your own system, configure an account webhook that includes deployment.alert. Rule creation and webhook subscription are separate operations with different permissions.
Follow platform events for destination rules, signatures, retries and duplicate handling. A webhook delivery is not a guarantee that a human has seen the alert. Read the metrics reference for current limits.