UptimeUptime Wiki

v0.1.28b (Early Access)

A follow-up to v0.1.28. A service that came up short of what you are paying for now gets topped up when there is room for it. The local API gained the one thing it was missing: an endpoint that explains why a world is unwell, rather than only listing what is in it.

Fixed

Services

  • A service that came up short is topped up once there is room. A Kubernetes cluster missing a worker, a database missing a copy, a content delivery service missing a location: these were checked with the same question used to decide whether your customer is being served, and that question is answered "yes" before the contract is fully built. A cluster serves on two thirds of its nodes, and a database serves on one copy. So anything short but still serving read as finished and was never looked at again. Buying the hardware it needed changed nothing, for the rest of the run.
  • The check now asks whether you have what you are paying for, which is a different question from whether the customer is currently being served, and both are asked in their own right. The one that decides whether to keep trying is now the same for every service, rather than each having grown its own answer.
  • A service with nowhere to go is left alone. Topping up looks first at whether it would actually seat more than is already running, so a full fleet does not shuffle live machines between hosts once an hour achieving nothing.

Added

The local API (experimental)

  • One endpoint that answers "why is this going wrong". /api/v1/diagnostics returns the whole health picture in a single read: open incidents and what recently resolved, machines the game could not place, control planes running degraded, requests you have not answered yet, capacity and cooling headroom, attacks in progress, where the money is going, and the engine's own log tail.
  • v0.1.28 shipped the inventory but not the diagnosis. You could list every host, customer and incident, which is enough to see that a customer is unhappy and not enough to see why. The parts that carry the reason were not exposed at all: an unanswered growth request, a segment with no room left, a degraded control plane. They are now.
  • A dashboard in your browser can now read it. v0.1.28 sent no cross-origin headers, which blocked a page you wrote yourself from fetching anything. Since the API is read-only and cannot be told to do anything, there was nothing for that to protect, so it now allows any origin and exposes the "how old is this data" headers along with it.
  • It is one call rather than a dozen, deliberately. Working out why something is wrong means comparing facts against each other: this incident, that customer, that pending request, that capacity number. Fetched separately those can come from moments either side of an update and quietly disagree, so a tool could reach a conclusion about a state your game was never actually in. One call is one consistent picture.

Notes

Saves from v0.1.28 load as normal. No save-format changes.

If a service in an existing save has been sitting short of what you contracted, it will fill itself in within the hour, provided the capacity is there. Nothing is moved to make room, and a service that is already whole is not touched.

The API remains experimental, on by default, read-only, and reachable only from your own machine. It is still the one part of the game we may change without warning.

Multiplayer sessions need every player on the same version, as with v0.1.28.

On this page