Platform status and incidents
Check Openstead service availability, follow incident updates, and distinguish platform issues from application-specific failures.
Openstead System status provides availability information, incident updates, and scheduled maintenance notices. It is hosted separately from the Openstead console, so you can check it without signing in to your workspace.
Read the affected components
Components separate the functions affected by an issue. Read the component name together with the incident description, affected scope, and timestamps. A problem creating new deployments does not necessarily interrupt applications that are already running.
| Component | What the check covers |
|---|---|
| Dashboard | Access to the Openstead console. |
| API | Availability of the platform API. |
| Authentication API | Availability of the sign-in API. |
| Deployment engine | Deployment-system connectivity and a recent processing heartbeat. |
| Deployment queue | Whether eligible deployment work is being claimed and expired work can be recovered. |
| Web service routing | HTTP routing to an Openstead-operated web service. |
| Private PostgreSQL queries | Authenticated read-only queries to a dedicated PostgreSQL database over Openstead's private network. |
| Private MySQL queries | Authenticated read-only queries to a dedicated MySQL database over Openstead's private network. |
| Checkout processing | Live payment-provider access, webhook availability, and reconciliation of completed Openstead collections with payment confirmations and purchased entitlements. |
| Website | Openstead's product information and pricing website. |
| Documentation | Guides, API reference, and the product changelog. |
A successful check confirms the particular function being checked. Deployment checks do not guarantee that an individual build completes, and the authentication check does not exercise every social sign-in flow. These checks do not establish that every customer application, database query, or payment works. Use your service's logs and metrics and health checks alongside platform updates.
The deployment-queue check distinguishes an eligible backlog from expected waits for capacity, another operation on the same service, workspace concurrency, or a monthly build allowance. A build that is already running can take time without indicating a queue outage. Use the deployment's own state and logs to diagnose that build.
The database checks use separate Openstead-operated databases, with private connections and restricted query accounts. They do not read customer data, expose database ports, or establish the condition of every customer's database. A successful query does not verify backups, restoration, or high availability.
The checkout check observes live processing without charging a card. When Bachs reports a completed Openstead collection, the monitor checks that its identity, amount, and currency match Openstead's records, that the signed confirmation was processed, and that the purchased credit, build minutes, or service term was recorded. Delayed confirmations and missing entitlements trigger operator alerts after a processing allowance. An idle checkout system can be operational without any recent payments; this check does not guarantee that a bank will approve a card or exercise every checkout screen.
Follow an incident
Incident updates explain what customers are experiencing and how recovery is progressing. The usual stages are:
| Stage | What it means |
|---|---|
| Investigating | We are checking the reported impact and determining the cause. |
| Identified | We have identified the cause and are working on a correction. |
| Monitoring | A correction is in place and we are checking recovery. |
| Resolved | We have verified that the affected platform function has recovered. |
Follow any action described in the notice. Avoid making several unrelated configuration changes while investigating a platform incident. After recovery, verify your own application and retry a failed operation only when appropriate; a resolved incident does not replay every failed customer request.
Check updates and incident history
Open the status page to read the current component states, active notices, and incident history. Revisit the incident while it is being investigated for the latest verified impact and recovery update. You do not need an Openstead console session to read the page.
Your workspace's webhooks and application alerts are separate. Workspace events describe your resources; the status page communicates Openstead platform availability.
Check planned maintenance
Maintenance notices identify the affected components, scheduled window and time zone, expected impact, and any action you need to take. Read progress updates to see when work begins and when it is complete. Do not assume that every maintenance window interrupts running applications.
Your own application's maintenance mode is a separate routing setting. Enabling it does not publish an incident or maintenance notice on Openstead's platform status page.
When only your application has a problem
An application can fail while the platform components are operational. Examples include a failed build command, an application exception, incorrect DNS, a missing environment variable, an exhausted connection pool, or a suspended service. A Free web instance waking from inactivity can also take time to respond.
Start with Troubleshoot a deployment. Compare the incident's reported scope with your error, deployment state, and recent configuration changes. If several functions fail and no matching incident is listed, report what you observe so it can be investigated.
Contact support
Contact Openstead support with the affected service or deployment ID, the time and time zone, the error or request ID, and the steps that produced the problem. Include a relevant status notice if one exists. Remove passwords, API keys, database credentials, payment details, and customer data from logs or screenshots.