Historically, when something fails on our side, our infrastructure, not yours, our API still responds with HTTP 200. The response body says "internal error," but the status code says everything was fine. Any monitoring tool watching status codes never sees the failure at all.

This is just to let you know we’re fixing that. Internal errors will soon return HTTP 500. Your monitoring catches what it should have caught all along, and so does ours, which means faster detection and faster fixes on infrastructure issues on our end.

Nothing about the failure itself changes, only the status code does. These are errors you could never have fixed on your end anyway: the error message never gave you anything actionable, and that hasn't changed.

We're rolling this out behind a feature flag, and aren’t going to start for about a month, so we can control the pace and revert immediately if needed. This also gives you some warning period about the change. This won’t affect every account in Spacelift, due to configurations, and usage, but there are some things to look for.

What to check

This is technically a breaking change, even though we expect the real-world impact to be small for most teams. It only matters if your integration reads HTTP status codes to drive logic, retries, alerts, pipeline gates, and so on.

• If you have custom automation built on our API, check whether it treats a 200 as "succeeded" without also checking the response body for errors.

• A request that previously came back as 200 during an internal error will now come back as 500.

• Everything else about the request and its outcome is unchanged.

If your integration already handles 5xx responses the way it should, you won't notice this change at all. Have questions? Please let us know. We’re here to help.