Monthly Render cost audit that flags unused services

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.