Operations

Monitoring

Understand the planned observability model for monitoring StrataGateway infrastructure, resource health, and operational signals.

Planned

Development Preview

StrataGateway monitoring capabilities are currently being designed. Metrics, retention periods, alerting behavior, dashboards, APIs, integrations, and available resource signals may change before public release.

Jump to article

Overview

StrataGateway monitoring is being designed to provide visibility into infrastructure health and resource behavior. The platform aims to offer a coherent observability model for operators and developers managing workloads on StrataGateway.

Clear infrastructure health visibility
Useful resource metrics
Predictable operational signals
Simple troubleshooting workflows
API-accessible monitoring data
Alerting support
Resource event history
Low-friction developer experience

StrataGateway monitoring capabilities are currently being designed. Metrics, retention periods, alerting behavior, dashboards, APIs, integrations, and available resource signals may change before public release.

Do not imply that production monitoring is currently available.

Monitoring model

The conceptual monitoring flow follows this pattern:

Conceptual flow

Conceptual flowtext
Infrastructure Resource
→ Metrics & Events
→ StrataGateway Monitoring Layer
→ Dashboard / API / Alerts

The intended monitoring layers include:

Infrastructure healthResource metricsNetwork behaviorOperational eventsAlerts

Exact metric names and collection intervals are still being defined.

Instance metrics

The following table outlines planned instance-level metrics:

MetricDescriptionStatus
CPU usageProcessor utilizationPlanned
Memory usageGuest memory visibility where supportedPlanned
Disk utilizationStorage usage and I/O indicatorsPlanned
Network trafficInbound and outbound trafficPlanned
Instance availabilityResource health signalPlanned
Load indicatorsCompute workload activityUnder Evaluation

Final metric availability may depend on instance type, operating system, telemetry configuration, and platform capabilities. Do not claim every metric will be available for every operating system or compute product.

Network metrics

Planned networking visibility includes the following potential signals:

Inbound trafficOutbound trafficPacket activityInterface statusPublic connectivityPrivate network activityFirewall-related operational events

Do not claim packet inspection or deep traffic inspection. Do not claim exact packet-loss or latency measurements unless explicitly implemented.

Networking documentation

Storage metrics

Storage monitoring is planned to provide visibility into storage-related resource behavior. Potential signals include:

Storage capacityUtilizationRead activityWrite activityI/O behaviorAttachment state

Exact storage metrics will depend on the final Block Storage and Object Storage implementations. Do not invent IOPS limits or throughput guarantees.

Health status

The planned concept of health states summarizes infrastructure-level operational signals for a resource:

Planned

Illustrative health model

Healthy

Operating within expected parameters.

Degraded

Experiencing reduced performance or partial impact.

Unavailable

Not reachable or not responding to health checks.

Unknown

Insufficient data to determine health state.

A resource health state is intended to summarize infrastructure-level operational signals. It does not necessarily represent application-level health inside a customer's workload.

Do not claim that StrataGateway can automatically determine whether a customer application is functioning correctly.

Metrics timeline

The planned metrics timeline concept supports the following illustrative time ranges:

Last hourLast 6 hoursLast 24 hoursLast 7 days
Planned

Illustrative monitoring interface

Metric retention periods and available time ranges are still being designed.

Avoid fake screenshots. Use existing panels and tables only.

Alerting

Alerting is planned but not yet publicly available. Potential future alert conditions include:

Resource unavailableHigh CPU utilizationStorage capacity thresholdNetwork connectivity issueInfrastructure eventBackup-related event

Illustrative alert model:

Alert flow

Alert flowtext
Metric / Event
→ Condition
→ Alert
→ Notification Channel

Potential notification channels:

EmailWebhookDashboard notification
Planned

Planned

Final alert conditions and notification channels are not yet finalized. Do not invent exact thresholds. Do not imply alert emails or webhooks currently work.

Resource events

Operational events are intended to help developers understand important resource lifecycle activity. Illustrative events:

EventCategory
instance.createdInstance
instance.startedInstance
instance.stoppedInstance
instance.rebootedInstance
instance.rebuiltInstance
instance.deletedInstance
network.createdNetwork
firewall.updatedFirewall
ssh_key.addedSSH Key

Event names are illustrative and not a final public event schema. Do not present them as existing production event names.

API access

Monitoring data is intended to become accessible programmatically through the StrataGateway API.

Planned

Illustrative endpoint

Illustrative endpoint

Illustrative endpointtext
GET /v1/instances/{instance_id}/metrics

Illustrative response

Illustrative response

Illustrative responseJSON
{
  "resource_id": "inst_7a91c2",
  "metric": "cpu_usage",
  "points": [
    {
      "timestamp": "2026-07-26T12:00:00Z",
      "value": 38.4
    }
  ]
}

Endpoint paths, response formats, metric names, timestamps, and query parameters are not finalized.

REST API documentation

Operational workflow

A recommended conceptual troubleshooting workflow:

1.

Check resource health

2.

Review infrastructure metrics

3.

Review recent events

4.

Check networking and firewall configuration

5.

Inspect workload logs inside the instance

6.

Review platform status

7.

Escalate when necessary

Platform monitoring vs. Application monitoring

StrataGateway monitoring is intended to provide infrastructure-level observability. Application-level tools such as application logs, APM, tracing, and application-specific metrics remain the responsibility of the workload owner unless future integrations provide additional capabilities.

Security considerations

Monitoring data may reveal infrastructure behavior and should be handled appropriately:

Monitoring data may reveal infrastructure behavior
Metrics access should follow account permissions
API tokens must be protected
Sensitive information should not be embedded in resource metadata
Monitoring interfaces should expose only authorized resources

Planned access controls will govern monitoring data access.

Authentication documentation

Planned integrations

Potential future integrations for monitoring workflows:

IntegrationPurposeStatus
REST APIProgrammatic metrics accessPlanned
CLIResource monitoring workflowsPlanned
Web DashboardVisual monitoring interfacePlanned
WebhooksEvent-driven notificationsUnder Evaluation
Prometheus-compatible workflowsExternal metrics workflowsUnder Evaluation
Grafana workflowsVisualization integrationsUnder Evaluation

Integration priorities may change as the monitoring architecture evolves. Do not claim official Prometheus or Grafana integrations exist. Do not use their logos. Do not imply partnership or certification.

Monitoring and service status

It is important to distinguish between:

Resource Monitoring

Individual customer infrastructure and operational signals.

Service Status

Availability and operational condition of StrataGateway platform services.

Link to the existing Service Status route only if it exists. Do not create a new status implementation as part of this task.

Was this page helpful?