Monitoring, alerts, and audit

Use the Dashboard for a quick health check, a resource page for its runtime details, Operations for work performed by Upvale, and Alerts for conditions that need attention. Audit log records who changed organization resources.

Dashboard

The dashboard summarizes projects, services, online nodes, and healthy clusters. Needs attention highlights offline nodes, firing alerts, unavailable services, and failed operations from the last 24 hours.

Online capacity shows the total CPU and memory capacity of online nodes, not their remaining free capacity. Recent operations links to individual operations so you can follow ongoing work or inspect a failure. Organization and personal notes appear here when present.

Start an investigation by opening the affected resource rather than treating every non-running item as broken. A paused scheduled job or stopped application may be intentional.

Service and node monitoring

Open an application or database and select Monitoring. For server metrics, open the node's page from Fleet.

Use the Time range selector to choose the last 15 minutes, 1 hour, 6 hours, 24 hours, 7 days, or 30 days. The available data depends on what the agent has reported and retained.

A missing series means data is unavailable for that range; it does not mean usage was zero. Node metrics cover the server, while resource metrics describe the workload scope. Use Deployments or the database topology view to identify which node and replica you are investigating.

For PostgreSQL HA, also inspect the database's member roles, replication state, and read-only connection status. A running container alone does not prove the whole database topology is healthy. See Databases.

Read and download logs

1. Open the application or database and select Logs.
2. Choose the service task or replica in the task selector.
3. Choose last 100, last 500, last 1000, or last 5000 lines.
4. Use Search loaded logs to filter the loaded lines.
5. Choose all output, stdout, or stderr.
6. Select Download to save the currently displayed lines.

Logs follow a running task; previous tasks show their available retained output. Refresh tasks updates the task list after a deployment. Retry reconnects a failed stream.

Search and download operate on the lines currently loaded in the viewer, not a full historical log archive. A download with an active search or source filter contains the visible filtered output.

Scheduled-job output belongs to a particular run. Open the job's run list, select a run, and inspect or download its output there. See Scheduled jobs.

Logs require View logs. Treat downloaded logs as potentially sensitive application data.

Follow an operation

Actions such as deploying an application, initializing a cluster, applying networking, or taking a backup create operations. A queued operation means Upvale accepted the work, not that it has completed.

Open the operation link shown after an action, or choose Operations in the sidebar. The list shows its type, status, resource, attempt count, error, queue time, and duration. Load more retrieves older entries.

Successful background route checks that made no changes are hidden by default. Use Show background checks to include them. Checks that synchronized a route or certificate are labeled accordingly.

Open an operation to see its Steps. Each step shows its status and available details. Failed deployments can include captured task errors, exit codes, container output, and service state under Failure diagnostics. If the page shows a retention deadline for those diagnostics, save any details you need before that time.

Upvale retries retryable failures up to the operation's limit. An exhausted retry count is a final failure, not evidence that the original cause has disappeared. Read the failing step, correct the cause, then retry through the relevant resource's action. There is no general retry button on every operation page; Compose, deployments, certificates, and other features provide their own recovery controls where supported.

A practical failure checklist

1. Read the failing operation step and its error, not just the final status.
2. Check the target node is online and has the expected Swarm role.
3. Check image access, task output, and the configured health check for a failed container start.
4. Check DNS, the route's target port, and certificate status for an unreachable website.
5. For persistent services, check the selected storage node and available disk space.
6. Retry after correcting the cause, then verify the resource's runtime state.

A successful operation confirms that operation's work. Continue to check application health and logs when the application itself may still be failing.

Notification channels

Open Alerts → Notification channels → Add channel. You need Manage alerts to configure channels and rules.

1. Enter a Name, such as on-call.
2. Choose Type.
3. Enter the destination and leave Enabled checked.
4. Select Create.
5. Use the channel's test action and check the result in Recent notification deliveries.

Webhook destinations must be publicly reachable HTTPS endpoints. They cannot point to private cluster or control-plane addresses. A generic webhook receives a JSON POST containing title, kind, severity, status, organization, context, and firedAt. Return a successful HTTP status promptly; the send has a 10-second timeout. The form does not offer custom authorization headers or payload templates.

Saved destinations are redacted in the list. When editing, leave the destination blank to keep the saved value, or enter a new one to replace it. A channel's type cannot be changed after creation; create a new channel for a different type.

Use the edit action to change a name, destination, or enabled state. Use the remove action to delete a channel you no longer need. Update affected rules if they should notify somewhere else.

If email reports that SMTP is unavailable, contact support. You do not configure the Upvale mail server in organization settings.

Delivery results

Recent notification deliveries shows the event, channel, result, attempts, and time. It also shows the latest delivery error where available.

• pending: queued for delivery or retry.
• sent: the configured destination accepted the send. For email, this does not guarantee inbox placement.
• failed: delivery did not complete; read the error and check the destination.
• simulated: the environment did not send a real external notification.

An alert event and its notification delivery are different records. A firing event can exist even if a channel is disabled, no channel was selected, or delivery failed.

Create an alert rule

1. Open Alerts → Alert rules → Add rule.
2. Enter a Name.
3. Choose a Condition.
4. Set Threshold if the condition uses one.
5. Choose Severity: Info, Warning, or Critical.
6. Choose Minimum duration: Immediate, 1 minute, 5 minutes, 15 minutes, or 1 hour.
7. Select Notify channels, or leave them empty to record events without sending notifications.
8. Keep Enabled checked and select Create rule.

Minimum duration means the condition must remain true for that long before firing. For example, a high-CPU rule with threshold 80 and duration 1 minute avoids alerting on a brief spike. This is an alert rule; it does not enable database read routing or automatically scale an application.

Severity labels the event; it does not change the threshold or trigger automatic remediation. Rules apply to relevant resources in the organization. The current rule form has no project or cluster selector.

You can edit the threshold, severity, duration, enabled state, and selected channels later. A rule's condition type cannot be changed after creation.

Available conditions

For the percentage-used conditions, a larger value is closer to exhaustion. Certificate expiry works in days remaining, so its threshold means approaching expiry rather than high utilization.

Review alert events

Recent alert events shows the alert, severity, status, and time. firing means the condition remains active; resolved means it has cleared. Notifications can report both transitions.

An email's View alert link opens the relevant organization's event, including its status and details. The header's alert menu also provides quick access to current events. Disabling notification delivery does not repair the condition that fired the alert.

Dismiss on the selected-alert card closes that view. It does not acknowledge, silence, or resolve the underlying event.

Audit log

Open Audit log to answer who changed something and when. Your role needs View audit log, and the organization's package must include audit logs.

Filter by From date, To date, Action type, Actor, and Target. Use Clear filters to return to the full list and Load more for older entries.

Each row shows the action, actor, target, source IP when available, and time. Audit records describe control-plane activity; container output is in Logs, and execution steps are in Operations. None of these screens is a general archive of outgoing email contents.

Historical records may be removed according to the platform's retention policy. Tenant settings do not expose a retention or database-cleanup control. Contact support if you need to discuss retention requirements.

Notes

Use the header's notes menu to create a note, or open Notes to view the list. Enter a title and content, then save. Open an existing note to edit it; use the archive action to remove it from the active list. Switch between Active notes and Archived notes to find earlier notes.

Notebook entries are private to your account within the selected organization. They are separate from the organization-wide notice that may appear on the dashboard.

Use notes for reminders and operational context. Keep credentials in Secrets, rather than notes or alert descriptions.