Can I compute deploy duration in the table?

Yes. Each deploy carries start and finish timestamps, so the agent writes the elapsed time as a field, or you store both timestamps and let an Airtable formula compute it.

Does this cover rollbacks?

A rollback is itself a deploy in Render's history, so it appears in list_deploys like any other and gets logged. Store the trigger field if you want to distinguish manual rollbacks from pushes.

RenderAirtable

Log every Render deploy to an Airtable table

A Render + Airtable agent flow

Ask any team how often they ship and you get a guess. A deploy log turns the guess into a number. This recipe keeps one without anyone maintaining it. The agent calls list_deploys for each Render service, reads the deploys it hasn't recorded, and writes each into an Airtable table with create_record: the service, the commit, the status, who triggered it, and the start and finish times. Render replies to the call rather than emitting events, so the agent runs on a cadence and tracks the last deploy id per service, so each deploy is logged exactly once. Over a few weeks the table answers deploy frequency, failure rate, and time-to-deploy without a dashboard.

The flow

Renderlist_deploys

Lists deploys matching the provided filters; returns all deploys for the service if none are given.

Airtablecreate_record

Create a new record in a table with the given field values.

Step by step

List deploys per service
The agent calls list_deploys for each service id, newest first. Each deploy carries an id, status, commit, trigger, and timestamps for when it started and finished.
Find the unlogged deploys
Hold the last deploy id recorded for each service. Deploys newer than that marker are the ones to log. Finished and failed deploys both get recorded; in-progress ones can wait until they settle so the status field is final.
Write the record
For each new deploy the agent calls create_record with the table fields: service, commit SHA, status, trigger, duration computed from the timestamps, and the date. The table becomes the source for change-failure rate and lead time.

Tell your agent

Every ten minutes, call Render list_deploys for each service, and for each finished deploy not yet logged, create an Airtable record with the service, commit, status, trigger, and duration.

Setup

This flow needs both servers connected to your agent. Follow each install guide:

Render install guide Airtable install guide

Worth knowing

list_deploys returns everything for a service when no filter is passed, which is a lot of history on the first run; scope to a recent window or the initial sync writes hundreds of rows.
A deploy's status changes as it runs. Log it only once it reaches a terminal state (live, build_failed, canceled), or you record an in-progress deploy and never update the row.

Questions

Can I compute deploy duration in the table?: Yes. Each deploy carries start and finish timestamps, so the agent writes the elapsed time as a field, or you store both timestamps and let an Airtable formula compute it.
Does this cover rollbacks?: A rollback is itself a deploy in Render's history, so it appears in list_deploys like any other and gets logged. Store the trigger field if you want to distinguish manual rollbacks from pushes.