Deployment Tracking in Render: Use the New Deploys Page¶

Deployment tracking in Render's new Deploys page showing deployed versions and the version currently in production.

When production breaks after a release, your first question is simple: what code is running? For a Git-backed service, Render’s Deploys page provides deployment history and displays the associated commit for Git-triggered deploys, as described in Render’s deployment documentation. Render also exposes RENDER_GIT_COMMIT, which contains the Git commit SHA for a Git-backed service.

Render documents RENDER_GIT_COMMIT as available to Git-backed Render services, including web services, background workers, and Cron Jobs, but not to image-backed services (Render-defined environment variables). A web service or continuously running worker can report it from its current process; a Cron Job must report it during the relevant execution. An image-backed service needs another build identifier, such as an image digest or an application-defined version.

Together, those sources provide a fast starting point without adding another platform. They establish the version context you need before investigating an AI agent, scheduled job, API, or worker.

What deployment tracking means—and what Render’s Deploys page adds¶

Deployment tracking connects four pieces of operational information:

The release you intended to ship.
The code version that was deployed.
The version currently serving production.
The release context needed during an incident.

This matters because CI/CD pipelines are foundational to modern software development and delivery. A pipeline may validate code, build an artifact, provision infrastructure, and deploy the result. Each stage can succeed or fail independently. Our guide to AI deployment pipelines from GitHub to production explains those stages in more detail.

Deployment tracking answers identity questions:

Which commit produced this deployment?
Did the intended commit reach production?
What deployment preceded it?
Did a rollback restore the expected version?

Runtime monitoring answers different questions:

Is the error rate increasing?
Is latency worse?
Are scheduled jobs exiting unsuccessfully?
Is an agent consuming more tokens or timing out?
Are API calls failing?

You need both kinds of information, but they are not interchangeable. If a Git-backed deployment exposes commit a13f09c in the dashboard or through Render’s runtime metadata, that identifies the revision associated with the deployment. It cannot, by itself, prove that the commit behaves correctly.

That distinction becomes important during incidents. Bad deployments are a significant source of service interruption and can lead to lost revenue and customer trust, according to Datadog’s deployment tracking overview. Establish the deployed version first, then use application logs, traces, tests, and metrics to diagnose its behavior. For a broader operational baseline, see this internal guide to AgentOps observability, logs, and cost monitoring.

Render documents its deployment methods, statuses, and Git-backed deployment behavior in Deploying on Render. In that documentation, Live means that the deploy is running for the service; “active” is not the documented deploy status to look for. For Git-triggered deploys, the Deploys page displays the associated commit information (Deploying on Render). Reporting RENDER_GIT_COMMIT from the relevant process or Cron Job execution is a useful application-level check, but the variable can be unavailable, omitted from logs, or reported by a different process than the one being investigated.

Find a deployment and verify which version is running¶

Use this section as the canonical version-identification procedure for incidents, release checks, and rollback verification.

Open the relevant service in the Render Dashboard, then open its Deploys page.
Read the deployment statuses before relying on timestamps or list order. Locate the deploy marked Live, which Render defines as the deploy running for the service (Deploying on Render).
Record that deploy’s timestamp and its source or commit information. For a Git-triggered deploy, Render displays the associated commit in deployment history (Deploying on Render). If no commit is displayed, do not infer one from a commit message, timestamp, or row position.
When available, have the relevant process report RENDER_GIT_COMMIT:
For a web service, use protected diagnostic output or controlled logs from the running application.
For a background worker, use output from the worker process being investigated.
For a Cron Job, inspect output produced during the specific execution being diagnosed.
Compare the runtime value with the intended commit and any commit shown on the Deploys page.
For an image-backed service, use an image digest or an application-defined build identifier because Render does not provide RENDER_GIT_COMMIT to image-backed services (Render-defined environment variables).

The order matters. Suppose the newest row shows a failed deployment for commit b72d410, while the next row is marked Live and shows commit a13f09c. Diagnose the running service as the Live deployment rather than assuming that the newer failed commit is in production. If the affected application process can report RENDER_GIT_COMMIT, compare its value with a13f09c before closing the identity check.

An application can report the Render-defined commit value without introducing another deployment-tracking platform:

import os

print(f"Running commit: {os.getenv('RENDER_GIT_COMMIT', 'unavailable')}")

Do not expose private environment data through a public endpoint. Return only the non-secret build identifier, protect the endpoint if appropriate, or write it to controlled application logs.

Once you have a commit identifier, inspect it locally:

git fetch origin
git show --stat --oneline a13f09c

Replace a13f09c with the commit reference shown by Render or reported by the relevant process. git show gives you the commit message, author, changed files, and patch summary.

Confirm that the commit exists on the expected production branch:

git branch --remotes --contains a13f09c

For a GitHub repository, open the corresponding commit URL:

https://github.com/OWNER/REPOSITORY/commit/a13f09c

Replace the owner, repository, and commit reference with your values.

You can also compare your intended local revision and the remote branch tip with the deployed commit:

git rev-parse HEAD
git show --oneline --no-patch a13f09c
git fetch origin
git rev-parse origin/main

There are three common outcomes.

The identifiers match.
The intended Git revision is running. Continue with application tests, logs, dependency checks, and relevant runtime signals.

The identifiers differ.
Stop assuming the latest merge is live. Check whether a newer deployment failed, whether you inspected the correct service, whether production follows another branch, or whether the evidence came from a different process or execution.

The expected deployment is incomplete or unsuccessful.
Investigate that deployment rather than debugging the Live version as if it contained the new code. Do not assume that the expected revision is executing until the corresponding deploy reaches the documented Live status and, when available, the relevant process reports the expected revision.

Consider a scheduled competitor-monitoring agent implemented as a Render Cron Job. You merge a change that modifies URL normalization, and the next run produces empty results. If the deployment history associates the Live deploy with commit a13f09c, and the affected execution also logs that value from RENDER_GIT_COMMIT, inspect the precise change:

git show a13f09c -- src/normalize.py

That does not prove that the normalization change caused the empty output. It narrows the investigation to the deployed code rather than the latest code on your laptop or the tip of a different branch.

Timestamps provide another useful correlation point. Compare the deployment time with:

The first failed scheduled run.
The first relevant application error.
A user report.
A change in an external API response.
A secrets or configuration update recorded through your operational process.

Treat timestamps as correlation, not causation. A failure appearing after a deployment may still come from an external dependency, expired credential, malformed input, or infrastructure issue.

Record the result in your incident notes:

Service: scheduled-enrichment-worker
Live deploy source commit: a13f09c
Runtime RENDER_GIT_COMMIT: a13f09c
Expected commit: a13f09c
Deployment time: <timestamp from Render>
Deployment status: Live
Runtime evidence: <endpoint, worker log, or Cron Job execution log>

If the Deploys page does not show a commit or the runtime variable is unavailable, record that limitation rather than filling the gap by inference. This small record prevents confusion when another developer pushes a commit during the investigation.

Diagnose a bad release and plan a rollback from deployment history¶

Suppose an AI lead-enrichment job begins failing after a release. Use this incident sequence.

1. Apply the canonical version-identification check¶

Follow the procedure in Find a deployment and verify which version is running. Then inspect the identified commit locally:

CURRENT=a13f09c
git show --oneline --no-patch "$CURRENT"

2. Find the previous known-good deployment¶

Review the deployment history and identify an earlier successful deployment that your tests or health signals show was known-good. For a Git-triggered deployment, record the commit displayed by Render (Deploying on Render).

PREVIOUS=84bc217
git show --oneline --no-patch "$PREVIOUS"

A successful deployment status indicates that the deployment process completed; it does not establish that every application path behaved correctly. If several deployments reached Live after the most recent healthy execution, compare their timestamps and revisions with that execution instead of automatically choosing the immediately preceding row.

3. Compare both releases¶

Inspect the commit range:

git log --oneline "$PREVIOUS..$CURRENT"
git diff --stat "$PREVIOUS..$CURRENT"
git diff "$PREVIOUS..$CURRENT"

For an agent job, focus on changes to:

Dependency files.
Entry points.
Model or API client configuration.
Retry and timeout logic.
Checkpoint schemas.
Secret names.
Storage paths.
Output validation.
Scheduling assumptions.

For jobs that may be replayed after failure, follow established retry and idempotency practices for scheduled AI jobs before rerunning production work.

4. Check runtime evidence¶

Inspect the logs and metrics for the affected path, reproduce the failure when safe, and check dependencies or configuration changed near the same time. Deployment history identifies candidate revisions; runtime evidence is still needed to establish root cause.

5. Roll back only when the service and deployment are eligible¶

Render currently documents one-click rollbacks for paid web services, private services, and background workers. Cron Jobs, static sites, and free web services are not listed as eligible for this rollback feature (Rollbacks).

For an eligible service, Render’s documented workflow is to locate a previous successful deploy on the Deploys page and select the rollback action for that deploy. Render then restores the selected deploy without rebuilding it; consult the current rollback documentation before confirming the action.

Verify that the selected deployment is the known-good release rather than merely the preceding successful row. If the rollback control is unavailable, use the service’s supported deployment workflow to deploy a known-good Git revision or image instead of assuming that every Deploys page supports rollback.

After the rollback or replacement deployment completes, repeat the canonical version-identification check. Confirm the resulting Live deployment and, when available, compare RENDER_GIT_COMMIT from the affected process or Cron Job execution before rerunning the health check or failed workload.

For stateful LangGraph agents, code rollback is only part of recovery. Existing checkpoints may have been written under the newer code. Review recovery and persistent checkpoint practices for LangGraph deployments before replaying production work.

Keep the investigation open after service recovery. A rollback limits impact; it does not explain why the release failed.

A no-extra-tool deployment tracking checklist for every release¶

Use this checklist for web services, workers, scheduled Python jobs, and AI agents.

Before deployment¶

[ ] Deploy from a traceable Git commit when using a Git-backed service.
[ ] Push the commit to the expected remote and branch.
[ ] Record the intended commit SHA.
[ ] Run tests for the affected application path.
[ ] Identify the previous known-good deployment before a risky change.

git rev-parse HEAD
git status --short
git log -1 --oneline

During deployment¶

[ ] Locate the new entry on the service’s Deploys page.
[ ] Read its documented status before drawing conclusions from its position or timestamp.
[ ] Record the deployment time and displayed source context.
[ ] If the new deploy fails, note which earlier deploy remains Live.

After deployment¶

[ ] Follow the canonical version-identification procedure.
[ ] Exercise a small health check.
[ ] Inspect startup and application logs.
[ ] Confirm that scheduled jobs return the expected exit code.
[ ] Check the application’s key runtime signals.
[ ] Keep the preceding known-good deployment identifiable.

For a Python agent, a basic executable smoke test can be as simple as:

import os
import sys

required = ("API_KEY", "OUTPUT_BUCKET")
missing = [name for name in required if not os.getenv(name)]

if missing:
    print(f"Missing required configuration: {', '.join(missing)}")
    sys.exit(1)

print("Configuration check passed")
sys.exit(0)

Render’s Deploys page provides deployment status and history, and it displays commit information for Git-triggered deployments (Deploying on Render). For Git-backed web services, background workers, and Cron Jobs, RENDER_GIT_COMMIT can provide an additional runtime identifier; image-backed services do not receive that variable and therefore need an image digest or application-defined build identifier (Render-defined environment variables).

Start with the information already available in Render: identify the Live deployment, compare its revision with the intended and previous known-good revisions, and then investigate application behavior. Add external tooling when you need longer retention, alerting, distributed correlation, or cross-service analysis.

The operational habit is simple: identify the deployed code before diagnosing its behavior. For agents and scheduled jobs, pair that version identity with controlled logs, reproducible tests, idempotent retries, persistent-state safeguards, and a recovery procedure appropriate to the Render service type.