# Monthly Render cost audit that flags unused services

> Every month, get a ranked list of the Render services and databases you are paying for but no longer using, with the estimated saving for each one.

- Workflow type: agent
- Services: Render, Google Sheets, Slack
- Categories: Operations, Engineering
- Published: 2026-08-09

## What it does

- Builds a full monthly inventory of everything running in your Render account, across every workspace you belong to, covering web services, background workers, cron jobs, static sites, and Postgres databases.
- Flags the waste: anything that has not shipped a deploy in over 90 days, leftover staging and preview environments spotted by their names, and oversized instances that are barely touching the capacity you pay for.
- Logs one row per resource to a Google Sheets tab each month, so the trend builds up over time and you can confirm cleanups actually happened.
- Posts a ranked cleanup list to Slack with the reasoning and estimated monthly saving for each item. It only ever recommends, and never suspends, deletes, or changes anything itself.

## What you'll need

- A Render account, plus an access key you can create in a minute from your Render account settings.
- A Google account and a spreadsheet where the monthly tracking tab will live.
- A Slack workspace and the channel where you want the cleanup list posted.
- A rough idea of which services are genuinely production, so the report can keep them out of the recommendations.

## Prompt

On the first business day of every month at 8am, audit my Render account and give me a ranked list of hosting resources I could clean up to bring my bill down. This workflow only ever recommends. It must never suspend, delete, resize, or otherwise change any resource, even when a case looks obvious.

Start with Render's List workspaces operation. My API key is account scoped and can reach every workspace I belong to, so build the inventory workspace by workspace and group the final report the same way.

For each workspace, use List services and List Postgres instances to build a complete inventory of web services, private services, background workers, static sites, cron jobs, and databases. These list operations return roughly 20 items per page and hand back a cursor, so keep requesting the next page until you reach the end. Do not assume a single call returns everything, because a partial inventory quietly produces a wrong report.

For every service in the inventory, call List deploys and record the date of the most recent successful deploy. That date is my proxy for whether anyone is still actively working on the thing.

Then pull utilization for each resource with Get CPU usage, Get memory usage, Get disk usage, and Get bandwidth usage, covering the month just ended. Pair those with Get CPU limit and Get memory limit so you can compare what a resource actually consumed against the capacity I am paying for. Keep both the average and the peak, because a service that idles all month but spikes hard once a day still needs its headroom.

Now flag the waste in three buckets. Stale: no deploy in more than 90 days. Leftover environments: names that read like throwaway infrastructure, such as staging, preview, test, demo, temp, old, copy, or a trailing pull request number. Oversized: CPU and memory sitting far below their limits for the whole month, where a smaller plan tier would still comfortably cover the observed peak. A resource can land in more than one bucket, and that combination is the strongest signal of all.

Estimate a monthly saving for every flagged item, based on its current plan or instance type and Render's published pricing. For an oversized resource, the saving is the difference between the current tier and the smaller one you are suggesting, not the full cost of the resource.

Append one row per resource to my Google Sheets tracking tab using Append Values, so the trend builds up month over month. Each row should carry the audit date, workspace, resource name, resource type, current plan or instance size, last deploy date, days since last deploy, average and peak CPU against the CPU limit, average and peak memory against the memory limit, disk usage, bandwidth used for the month, which flags were raised, and the estimated monthly saving. Always append and never overwrite earlier rows, so I can follow the same resource across months and see whether it ever got cleaned up.

Finally, post the cleanup list to Slack with Send a Message. Rank it by estimated monthly saving, highest first, and group it by workspace. For each item give the resource name, what kind of resource it is, one plain sentence explaining why it was flagged, the estimated monthly saving, and a recommended action such as delete, suspend, or drop to a smaller plan. Open the message with the total estimated monthly saving and the number of resources flagged, and close it with a clear reminder that nothing was changed and every item needs a human to action it.

Be conservative throughout. If something looks idle but you cannot confirm it, say so rather than recommending removal. Put anything that looks like production, sits behind a custom domain, or is a database holding real data into a separate section at the bottom with a warning, even when its metrics look low. If a workspace returns nothing, or metrics are unavailable for a particular resource, note that explicitly in the report rather than skipping it silently, so a gap in the data never reads as a clean bill of health.

## How to customize

- Change the timing: run it quarterly instead of monthly, or move it off the first business day to whatever suits your billing cycle.
- Adjust the staleness threshold: 90 days is the default, drop it to 30 days for a fast moving team or raise it to 180 if you keep long lived services around.
- Tune the naming patterns treated as leftovers, so words your team actually uses for throwaway environments get caught.
- Change where it lands: pick a different Slack channel, send it straight to whoever owns the bill, or point it at a different spreadsheet.

## Example output

Render cleanup audit for March
12 resources flagged across 3 workspaces. Estimated saving: $187 per month.

Acme Production workspace
1. acme-api-staging (web service, Standard). $25/mo. No deploy in 214 days and the name marks it as a staging copy. Recommend deleting after confirming nobody is pointing at it.
2. acme-pg-preview-441 (Postgres, Basic 1GB). $19/mo. Left over from pull request 441, closed in December. Recommend deleting once you have taken a backup.
3. acme-worker (background worker, Standard). $18/mo. Peak CPU 8% and peak memory 210MB of 2GB all month. Recommend dropping one plan tier.

Side Projects workspace
4. old-scraper (cron job, Starter). $7/mo. Last deploy 402 days ago. Recommend deleting.

Needs a human look, not recommended for removal
- acme-db-main (Postgres, Pro). Low CPU, but it is your production database and holds real data.

Nothing was changed. Every item above needs someone to action it.

## FAQ

### Will this shut down or delete any of my services?

No. This is deliberately a read only audit. It looks at your resources and writes up what it finds, then leaves every decision to you. Nothing gets suspended, deleted, or resized unless a person goes and does it.

### Does it cover all of my Render workspaces?

Yes. It starts by listing every workspace your account can reach, then works through each one and groups the final report by workspace, so a forgotten service in a side project does not slip through.

### How does it decide something is unused?

It combines three signals: how long it has been since anything was deployed, how the name reads (things like staging, preview, test, or an old pull request number), and how much of the CPU and memory you pay for is actually being used. Anything uncertain gets called out as uncertain rather than recommended for deletion.

### What if I only have a handful of services?

It still pays off. Small accounts are exactly where a forgotten staging database or an idle background worker quietly runs for months, and one line item can be a meaningful share of a small bill.

### Do I need both Google Sheets and Slack?

The spreadsheet is what makes the month over month trend possible, and Slack is how the list reaches you. You can swap Slack for another channel your team reads, or drop the spreadsheet if you only care about the current month.

Use this prompt in General Input: https://www.generalinput.com/prompts/monthly-render-cost-audit-that-flags-unused-services