Status
Check the live health of Devpilot services, view active incidents, and browse historical incident reports.
Status
The Devpilot Status page is the public source of truth for platform health. It shows the current state of every Devpilot service, any open incidents, and the history of past disruptions and maintenance windows.
Where to find it
Visit /status in your browser. No sign-in is required — this page is open so that anyone on your team (or customers watching your deployments) can check whether Devpilot is up.
The page auto-refreshes every 30 seconds, so you can leave it open in a tab during a release and watch for any regression in real time.
What the status page shows
Global status banner
At the top of the page, Devpilot rolls up the state of every active component into a single global status value. Its possible states, in order of severity, are:
| State | Meaning |
|---|---|
| Operational | All systems are running normally. |
| Under maintenance | A planned maintenance window is in progress for at least one component. |
| Degraded performance | A component is slower than usual but still working. |
| Partial outage | A component is unavailable, but the rest of the platform is fine. |
| Major outage | A significant portion of Devpilot is unreachable. |
The banner always reflects the worst currently active component state. If any component is in a major outage, the banner shows Major outage even if the rest of the platform is healthy.
Components list
Below the banner you see each Devpilot component — the building blocks of the platform such as the API, web dashboard, deployment workers, and supporting infrastructure. Each row shows:
- The component name and optional group it belongs to (for example, "Core APIs" or "Infrastructure").
- A short description of what the component does.
- The current status (one of the five values above).
- A last checked timestamp so you can see how fresh the reading is.
Components are kept in a stable order set by the Devpilot team so the most important services appear first. Only active components are shown — retired components are hidden automatically.
Active incidents
If anything is currently wrong, an active incidents section appears under the components list. Each incident shows:
- The incident title and a plain-language summary.
- Its impact —
none,minor,major, orcritical. - Its status as the team works through it:
investigating,identified,monitoring, orresolved. - The components it is affecting.
- A stream of updates, each with a timestamp, so you can follow the play-by-play.
- The started at time, and the resolved at time once it closes.
Incidents disappear from the active list as soon as their status becomes resolved, at which point they move into the history view.
| Impact | What it typically means |
|---|---|
| none | An informational notice — no functional disruption. |
| minor | A subset of users may notice slower responses or retries. |
| major | A clear disruption: many users cannot complete a common flow. |
| critical | Widespread outage or data risk. Treat as top priority. |
An incident moves through these statuses as the team works on it:
- investigating — the team has acknowledged the incident and is actively digging in.
- identified — root cause (or at least a reliable workaround) has been found.
- monitoring — a fix is in place and the team is watching to confirm recovery.
- resolved — the incident is closed and Devpilot is back to normal.
Each status change creates a new update entry you can read in the incident timeline.
Incident history
The Status page links to a full history view that paginates through every past incident (20 per page), newest first. Use it to:
- Confirm whether an issue you experienced earlier was acknowledged by Devpilot.
- Read the resolution notes after a major outage.
- Audit uptime over a time range.
Maintenance windows
Planned maintenance is represented as an incident with a state of under maintenance on the affected components. When a maintenance window is scheduled, you will see:
- The components that will be touched.
- A description of what is changing.
- The start time (and, once complete, the end time).
If you have production deployments, check the Status page before kicking off a release. Deploying during a partial outage or maintenance window can lead to confusing failures.
Staying informed
Because the Status page is a plain URL, you can:
- Bookmark it in your browser.
- Pin it in your team chat for quick reference.
- Embed a link to it in your own internal runbooks.
- Open it in a side monitor during releases — it refreshes itself every 30 seconds.
Reporting a problem
If you are hitting an issue that is not reflected on the Status page:
Refresh once
Wait 30 seconds or reload the page — the component check may update shortly.
Capture evidence
Grab a screenshot, the exact time you saw the problem (with timezone), and any error messages or deployment IDs.
File a support request
Open the Contact page, pick Support, and paste the evidence into the message. If the problem is widespread, the team will convert your report into a public incident.