Read a release and its build log with the Apps API

Read a release to follow it while it builds and starts, to find out why it failed, and to check the health of each of its replicas. Every member of an organization can read its apps' releases. The API names a release deployment, in its paths and its objects.

In the dashboard, each release is on the Releases tab of the app's page under App Deployment, with its build log, and the Logs tab shows what the app writes while it runs (Deploy, promote and roll back releases, Logs and metrics). This page covers the Apps API, which scripts written for Apps keep using.

• Send your access token as Authorization: Bearer $CORITAN_TOKEN (Authentication).
• Find the release's ID in the app's history (List releases). The five newest also come with the app itself.
• Releases explains what each status means.

A release of a git app keeps the last 64 KB of its build log. The log hides the repository's access token and every secret build value of six characters or more, which appear as [redacted]. A release of an image has no build, so it has no log, and a redeploy or a rollback that reuses an image has none either.

The end of the log is where a failure usually is. truncated says when the build wrote more than the 64 KB that are kept (Read the build log through the API).

A release's replica_list holds every replica it has had, with its region, its state, when it was last checked, its last error and when it started. health_failures counts a replica's failed health checks in a row.

A replica's last error says what went wrong, such as Health check on /healthz: HTTP 500 or The app did not pass its health check within 10 minutes. Health check on /: the connection failed. The dashboard calls each replica an instance, on the app's Instances tab.

For an organization's app, send the same requests under /api/v1/orgs/{org_slug}/apps (organization apps reference).

GET /api/v1/client/apps/{app_uuid}/deployments/{deployment_uuid} returns the release with every replica it has had in replica_list:

curl https://api.coritan.com/api/v1/client/apps/3c9e2f4a-8b1d-4f6e-a2c7-5d8b9e0f1a21/deployments/1d7b4e9a-5c2f-4a8e-9d6b-2f8e5a1c7b11 \
  -H "Authorization: Bearer $CORITAN_TOKEN"

{
  "deployment": {
    "uuid": "1d7b4e9a-5c2f-4a8e-9d6b-2f8e5a1c7b11",
    "status": "failed",
    "source": "git",
    "trigger": "push",
    "git_ref": "main",
    "git_sha": "9f2c1e7b4a6d8e0f1a2b3c4d5e6f708192a3b4c5",
    "commit_message": "Move the health check to /healthz",
    "commit_author": "Alex Example",
    "image_ref": null,
    "image_digest": null,
    "artifact_sha256": "5b2d0c9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c",
    "artifact_size": 50541320,
    "runtime_image": "ghcr.io/parkervcp/yolks:nodejs_22",
    "start_command": "npm run start",
    "regions": ["fra", "iad"],
    "actor_type": "webhook",
    "error": "Replicas could not start in fra: The app did not pass its health check within 10 minutes. Health check on /healthz: HTTP 404",
    "is_current": false,
    "in_flight": false,
    "can_rollback": false,
    "replicas": {"healthy": 0, "unhealthy": 0, "starting": 0, "total": 0},
    "build": {
      "uuid": "e2a9c4d1-3b5f-4e7a-9c8d-1f2e3a4b5c6d",
      "status": "succeeded",
      "strategy": "container",
      "error": null,
      "attempts": 1,
      "log_bytes": 48211,
      "started_at": "2026-09-26T10:05:04Z",
      "finished_at": "2026-09-26T10:07:41Z",
      "created_at": "2026-09-26T10:05:00Z"
    },
    "ready_at": null,
    "promoted_at": null,
    "finished_at": "2026-09-26T10:18:02Z",
    "created_at": "2026-09-26T10:05:00Z",
    "updated_at": "2026-09-26T10:18:02Z",
    "replica_list": [
      {
        "location": "fra",
        "state": "failed",
        "health_failures": 0,
        "last_health_at": null,
        "last_error": "The app did not pass its health check within 10 minutes. Health check on /healthz: HTTP 404",
        "created_at": "2026-09-26T10:07:45Z",
        "drained_at": null
      }
    ]
  }
}

The example shows one replica of several. App and release fields describes every field. These say the most:

The version

A release of a git app has the branch or ref it built and the ID of the commit it checked out. A release that a push started also has the commit's message and author. A git release's build output has its artifact_sha256 and artifact_size, the runtime_image its replicas run (such as Node 22's) and the start_command they run there; its image_ref is null. A release of an image shows its image's reference and, once known, its digest.

Where it came from

source is git, image, upload, redeploy, rollback or promote. trigger says what started it: push for the push webhook, rebuild for a rebuild, rollback for a rollback, deploy_hook for a deploy hook, and manual for a deploy of a branch or an image, a redeploy, an upload or a promotion that you or a member of your organization asked for. The Started by column of the dashboard's Releases tab words these (What started a release). actor_type is user for a person signed in to Coritan, staff for a staff console session, webhook for a push, and admin when Coritan staff started it.

Its progress

status, in_flight while it is on its way, is_current while it is the live release, and can_rollback. replicas counts the replicas in provisioning, starting, healthy and unhealthy: starting counts the first two, and total all four.

What went wrong

When a release fails or is cancelled, its error says why. A release that went live without a region also says so there.

The build

For a release of a git app, its build's status (queued, running, succeeded, failed or canceled), its strategy (container, a build container on the platform), how many attempts it took, and when it started and finished. A build that stops reporting is tried once more.

In each replica, health_failures counts its failed health checks in a row, and drained_at is when it stopped taking requests.

GET /api/v1/client/apps/{app_uuid}/deployments/{deployment_uuid}/log returns the end of the build log:

curl https://api.coritan.com/api/v1/client/apps/3c9e2f4a-8b1d-4f6e-a2c7-5d8b9e0f1a21/deployments/1d7b4e9a-5c2f-4a8e-9d6b-2f8e5a1c7b11/log \
  -H "Authorization: Bearer $CORITAN_TOKEN"

{
  "build": {"uuid": "e2a9c4d1-3b5f-4e7a-9c8d-1f2e3a4b5c6d", "status": "succeeded", "strategy": "container"},
  "log": "Fetching https://github.com/example/web-shop main at 9f2c1e7b4a6d.\nChecked out 9f2c1e7b4a6d.\nDetected Next.js on Node 22.\n> npm install\n...",
  "log_bytes": 48211,
  "truncated": false
}

log is the text, up to 64 KB. log_bytes is how much the build wrote in all, and truncated is true when that is more than log holds. A release of an image answers {"build": null, "log": "", "log_bytes": 0, "truncated": false}. The log grows while the build runs, so read it again to see new lines.

You know where the release is, and why when it failed. Troubleshoot the Apps API lists the common causes and their fixes.

Release not found

The ID belongs to another app's release, or to none. Check both IDs against the app's history.

The log is empty

A release of an image has no log, nor does a release that reused an image. A build that has not started has written nothing yet.

The log starts partway through

The build wrote more than 64 KB, and only the end is kept.

• Deploy an app with the Apps API
• Roll back to an earlier release
• App and release fields
• Logs and metrics, for what the app writes while it runs