Service Status

Overview

The Service Status system will provide platform-level health information for StrataGateway infrastructure. It is designed to communicate real-time service availability, active incidents, scheduled maintenance, and historical availability data to customers and stakeholders.

The StrataGateway public service status system is currently being developed alongside the platform. Production availability data, incident history, uptime metrics, and public status feeds will only be published once relevant services become operational.

This page documents the planned service status system. It does not represent a live operational status dashboard. StrataGateway does not currently operate a public production cloud.

Purpose

The Service Status system is intended to serve as the authoritative source for StrataGateway platform health. Its planned responsibilities include:

Platform-wide service health visibility

Regional availability reporting

Incident detection, communication, and resolution tracking

Scheduled maintenance planning and notification

Customer-facing operational transparency

Historical service information for compliance and planning

This page describes the intended design. No production status system is currently operational.

Service Status Model

The planned status state model defines a fixed set of service health states:

StatusMeaning

OperationalThe service is functioning normally with no known issues.

Degraded PerformanceThe service is experiencing reduced performance but remains functional.

Partial OutageA subset of the service is unavailable or significantly impacted.

Major OutageThe service is largely or completely unavailable.

MaintenanceScheduled maintenance is in progress. Some functionality may be temporarily unavailable.

UnknownThe current status cannot be determined at this time.

These are status definitions. They are not current live statuses. StrataGateway does not currently operate a public production cloud. Do not display green “Operational” badges next to real StrataGateway services as though they are currently running.

Planned Services

The following service categories are expected to appear in the public service status system. Only services that exist in the current StrataGateway product architecture or roadmap are included.

ServiceScopeStatus

Cloud ComputeCompute instances, lifecycle operations, and instance healthPlanned for monitoring

NetworkingPublic and private networking, load balancing, DNSPlanned for monitoring

Control PlaneAPI gateway, authentication, resource orchestrationPlanned for monitoring

APIREST API endpoints, authentication, rate limitingPlanned for monitoring

StorageBlock storage, object storage, backup systemsPlanned for monitoring

AuthenticationIdentity, tokens, SSH keys, access managementPlanned for monitoring

DashboardCustomer dashboard, service status page, user-facing UIPlanned for monitoring

Do not assign these services live operational states. Use wording such as “Planned for monitoring” or “In Development” when referring to their status visibility.

Regional Status

Region-level availability is expected to work in conjunction with platform-wide status. Future regional status could distinguish platform-wide incidents from region-specific incidents.

Do not claim any region is currently live. Do not display “fra-1 Operational” or similar production-style claims.

Illustrative region identifiers for future reference:

Region CodeLocationNote

fra-1Frankfurt, GermanyIllustrative example

nyc-1New York, USAIllustrative example

sgp-1SingaporeIllustrative example

Future regional status could distinguish platform-wide incidents from region-specific incidents.

Incident Lifecycle

A typical planned incident workflow follows these stages:

Investigating

Potential issue detected; root cause not yet confirmed. Engineers are actively analyzing.

Identified

Root cause confirmed. Mitigation or resolution plan is in progress.

Monitoring

Fix deployed or workaround applied. Service is being monitored for stability.

Resolved

Service restored to normal operation. Post-incident review may follow.

These are workflow definitions only. Do not create fake incidents, timestamps, or historical records.

Incident Updates

Planned fields for a future incident update payload:

FieldDescription

Incident TitleBrief, human-readable summary of the issue

Current StatusOne of: Investigating, Identified, Monitoring, Resolved

Affected ComponentsList of impacted services and components

Affected RegionsList of impacted regions, if applicable

Started AtISO 8601 timestamp when the incident began

Latest UpdateISO 8601 timestamp of the most recent status change

Resolution StateWhether the incident is resolved or still active

Illustrative example

Illustrative incident object

Illustrative incident objectJSON

{
  "id": "inc_example",
  "title": "Elevated API latency in fra-1",
  "status": "monitoring",
  "components": ["API", "Authentication"],
  "regions": ["fra-1"],
  "started_at": "2026-07-28T14:32:00Z",
  "latest_update": "2026-07-28T15:10:00Z",
  "resolved": false
}

Do not create fake outage dates or pretend incidents occurred. Prefer conceptual structure over fake historical content.

Scheduled Maintenance

Planned maintenance communication may include the following information in the future:

FieldDescription

Maintenance TitleDescriptive name for the maintenance window

Affected ComponentsList of services/components that will be affected

Affected RegionsRegions where maintenance will occur

Planned StartISO 8601 timestamp for maintenance start

Planned EndISO 8601 timestamp for expected completion

Expected ImpactDescription of expected customer impact

Completion UpdateFinal status after maintenance concludes

Do not invent actual maintenance events. Do not invent scheduled dates. State clearly that no production maintenance calendar should be inferred from the example.

Notifications

Potential channels for future status update delivery:

ChannelPurposeStatus

EmailSubscriber-based email notifications for incidents and maintenancePlanned

WebhookHTTP callbacks for real-time integration with customer systemsUnder Evaluation

RSS / AtomStandard feed for incident and maintenance updatesPlanned

Dashboard NotificationsIn-application banner or toast for active incidentsUnder Evaluation

Inspect existing project plans before presenting any channel as committed. Do not claim subscription functionality currently exists.

Status History

Historical incident and availability records will accumulate only after production services begin operating.

The current page must not fabricate historical uptime. Do not invent:

Past 90 days
Past incidents
Zero incidents
100% uptime

Instead clearly state that meaningful history cannot exist before operational production data exists.

Availability Metrics

Conceptually, future availability measurement may include:

Service availabilityRegional availabilityIncident durationMaintenance exclusions

Do not state specific uptime targets such as 99.9%, 99.95%, 99.99%, or 100%. Do not publish performance targets unless they already exist as verified project policy. Explain that metrics must be derived from measured production operation.

Status API

The concept of a future machine-readable service health endpoint:

Planned

Illustrative future API

Illustrative endpoint

Illustrative endpointtext

GET /v1/status

Illustrative response

Illustrative responseJSON

{
  "services": [
    {
      "id": "compute",
      "name": "Cloud Compute",
      "status": "operational",
      "regions": {
        "fra-1": "operational",
        "nyc-1": "operational"
      }
    },
    {
      "id": "networking",
      "name": "Networking",
      "status": "degraded_performance",
      "regions": {
        "fra-1": "degraded_performance",
        "nyc-1": "operational"
      }
    }
  ],
  "last_updated": "2026-07-28T18:30:00Z"
}

Do not claim the endpoint exists today. Do not invent a finalized schema. If showing JSON, label it clearly as illustrative.

Example conceptual response fields could include:

servicestatusregionupdated_at

Monitoring Relationship

It is important to distinguish between two related but distinct observability domains:

Customer Resource Monitoring

Visibility related to customer infrastructure or platform monitoring concepts.

Platform Service Status

Availability and incident state of StrataGateway platform services.

Conceptual relationship:

Conceptual distinction

Conceptual distinctiontext

Monitoring
→ Customer resource metrics, events, health signals

Service Status
→ Platform-level availability, incidents, maintenance

Distinct but complementary systems.

Monitoring documentation

Do not duplicate the Monitoring article. Service Status represents StrataGateway platform availability. Monitoring represents customer resource visibility.

Availability and SLA

Service Status reports operational state. A Service Level Agreement (SLA) is a contractual commitment. They are related but distinct.

Service Status

Reports current and historical operational state of platform services.

SLA

Contractual service commitment with defined targets, credits, and terms.

StrataGateway must not claim an SLA unless an actual SLA policy exists in the repository or project. State that availability targets and SLA commitments will be documented separately when finalized. Do not invent credits, percentages, guarantees, exclusions, or compensation policies.

Operational Transparency

StrataGateway's intended approach to infrastructure communication:

Clear incident communication without inflated availability claims

Accurate service state representation at all times

Timely updates with appropriate regional and component scope

Post-incident learning and process improvement when appropriate

Present these as design principles / intended operational direction. Do not claim operational processes that have not yet been implemented.

Next steps

Changelog