Linking Render as a source
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.
Contents
The Render connector syncs your services, deploys, one-off jobs, service events, managed databases, blueprints, disk snapshots, Postgres query insights, and service metrics into the PostHog Data warehouse, so you can analyze deploy frequency, job outcomes, database performance, and infrastructure changes alongside your product data.
Prerequisites
You need a Render account with permission to create an API key. An API key grants access to every workspace your user belongs to.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
When linking Render, you'll need:
- API key – create one under Account settings → API keys in the Render Dashboard.
- Workspace ID (optional) – if your user belongs to multiple workspaces and you only want to sync one, enter its workspace ID (starts with
tea-). You can find it in your workspace settings, or by syncing theownerstable first. Leave empty to sync every workspace the key can access.
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
Deploys, jobs, and events are fetched per service, so syncs make one or more requests for each service in your workspace. Use incremental sync for these tables to keep ongoing syncs fast.
Metrics tables (CPU, memory, HTTP requests, HTTP latency, instance count, and bandwidth) are opt-in and not synced by default. Enable them individually after connecting the source. These tables use incremental sync and merge on timestamp.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Workspace ID (optional) | text | No |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
owners | Workspaces (users and teams) that the API key's user belongs to. Other resources reference their owning workspace via ownerId. | Full refresh | — | — |
projects | Projects that group related services and databases into environments (e.g. production and staging). | Incremental, Full refresh | updatedAt, createdAt | — |
environments | Environments within a project (e.g. production, staging), listing the services, databases, and env groups they contain. | Full refresh | — | — |
services | Services in the workspace: web services, static sites, private services, background workers, and cron jobs. | Incremental, Full refresh | updatedAt, createdAt | — |
deploys | Deploys for each service, with status, trigger, and timing — one row per deploy per service. | Incremental, Full refresh | finishedAt, updatedAt, createdAt | — |
jobs | One-off jobs run against each service: standalone tasks that run to completion using the service's most recent successful build. | Incremental, Full refresh | finishedAt, startedAt, createdAt | — |
events | Operational events for each service: deploys, builds, restarts, suspensions, autoscaling, disk and plan changes, and more. | Append only, Full refresh | timestamp | — |
custom_domains | Custom domains attached to each service, with verification status. | Full refresh | — | — |
env_groups | Environment groups: named sets of environment variables and secret files shared across services. | Incremental, Full refresh | updatedAt, createdAt | — |
postgres | Managed Postgres instances in the workspace, with plan, status, and configuration. | Incremental, Full refresh | updatedAt, createdAt | — |
key_value | Key Value (Redis-compatible) instances in the workspace, with plan, status, and configuration. | Incremental, Full refresh | updatedAt, createdAt | — |
disks | Persistent disks attached to services, with size and mount path. | Incremental, Full refresh | updatedAt, createdAt | — |
instances | Running instances of each service. A scaled service has one row per instance. | Full refresh | — | — |
members | Users who belong to each workspace, with their workspace role and status. | Full refresh | — | — |
audit_logs | Workspace audit log: material actions performed by members, API keys, and Render itself. Needs a Pro workspace plan or higher and an admin API key. | Append only, Full refresh | timestamp | — |
blueprints | Blueprints: infrastructure-as-code definitions (render.yaml) that create and update services from a Git repository. | Full refresh | — | — |
blueprint_syncs | Sync history of each Blueprint: every time Render applied the Blueprint file to the workspace. Syncs that are planned but not yet approved are not included. | Full refresh | — | — |
disk_snapshots | Point-in-time snapshots of each persistent disk, which a disk can be restored from. | Full refresh | — | — |
postgres_top_queries | The top 50 queries by total execution time on each Postgres database, from pg_stat_statements. Statistics are cumulative since they were last reset. | Full refresh | — | — |
postgres_table_scans | Number of sequential scans run against each table on each Postgres database. A high count on a large table often points to a missing index. | Full refresh | — | — |
metrics_cpu | CPU usage of each service. One row per service, time series and time bucket. Render keeps 7 to 30 days of metrics, depending on the workspace plan. | Incremental, Full refresh | timestamp | — |
metrics_memory | Memory usage of each service. One row per service, time series and time bucket. Render keeps 7 to 30 days of metrics, depending on the workspace plan. | Incremental, Full refresh | timestamp | — |
metrics_http_requests | HTTP request count of each service. One row per service, time series and time bucket. Render keeps 7 to 30 days of metrics, depending on the workspace plan. | Incremental, Full refresh | timestamp | — |
metrics_http_latency | HTTP response latency quantiles of each service. One row per service, time series and time bucket. Render keeps 7 to 30 days of metrics, depending on the workspace plan. | Incremental, Full refresh | timestamp | — |
metrics_instance_count | Number of running instances of each service. One row per service, time series and time bucket. Render keeps 7 to 30 days of metrics, depending on the workspace plan. | Incremental, Full refresh | timestamp | — |
metrics_bandwidth | Outbound bandwidth usage of each service. One row per service, time series and time bucket. Render keeps 7 to 30 days of metrics, depending on the workspace plan. | Incremental, Full refresh | timestamp | — |
Troubleshooting
- If you see an authentication error, your API key is invalid or has been revoked. Create a new key in your Render account settings, then reconnect.
- Render rate limits API requests per user. Syncs back off and retry automatically, but very large workspaces may sync slowly on the first run.
- Postgres query insights (top queries and table scans) may be unavailable for some database instances, such as suspended ones. These tables skip unavailable databases and continue syncing the rest.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.