Monitor, scale, and the rest of the toolkit — Pair-program with Render: deploy, debug, and monitor with the Render plugin

tinylink is back to green. We’ve used the plugin to deploy, break, and fix it. Two pieces left: confirm with the monitoring slash command, and zoom out to see what else lives in the toolkit.

1. /check-render-status

The plugin’s other built-in slash command is the read-only counterpart to /deploy-to-render:

/check-render-status

The agent invokes render-monitor, which fans out a handful of MCP calls and summarizes the result:

Loading skill: render-monitor.

Calling render -> list_services()...
Calling render -> get_metrics(serviceId="web-srv-ghi789", window="1h")...
Calling render -> list_deploys(serviceId="web-srv-ghi789", limit=5)...
Calling render -> get_metrics(serviceId="postgres-srv-abc123", window="1h")...

Status - tinylink workspace, last hour:

  tinylink-web (web)
    deploy:    live (5m ago, fix: bind uvicorn to 0.0.0.0)
    HTTP 5xx:  0 / 312 requests
    p95:       38ms
    CPU/mem:   8% / 110 MB

  tinylink-db (postgres)
    storage:   12 MB / 1 GB
    conns:     1 / 97
    cpu:       2%

  tinylink-kv (keyvalue)
    keys:      14
    memory:    3 MB / 25 MB

  tinylink-prune (cron)
    last run:  not yet (next at 03:00 UTC tomorrow)

All green.

You’re looking at live metrics from the Render API, served back to you in the same chat where you wrote the code. That’s the headline benefit of MCP - there’s no context switch to the Render Dashboard for routine checks.

2. Ask about autoscaling

A small URL shortener doesn’t need autoscaling, but the conversation is worth seeing because it pulls a different skill:

Should I turn on autoscaling for tinylink-web? It's on the starter plan.

Loading skill: render-scaling.

Looking at the last 24h of metrics:
  Calling render -> get_metrics(serviceId="web-srv-ghi789", window="24h")...
  CPU p95: 11%, memory p95: 130 MB, request rate p95: 2 req/s.

Recommendation: not yet.

Autoscaling is most valuable when:
  - your CPU regularly exceeds 70%, or
  - your traffic is bursty (large daily peaks vs troughs), or
  - you can't afford queueing under load.

You're at ~11% CPU with smooth traffic. A single Starter instance is
fine; turning on autoscaling now would cost more without changing
behavior.

When you DO want it, here's the Blueprint snippet (render-scaling skill):

  scaling:
    minInstances: 1
    maxInstances: 3
    targetCPUPercent: 70

Word of warning: Render disables autoscaling on the free plan, and
the Starter plan caps at 3 instances. Bump to Standard if you expect
more.

That’s render-scaling doing what skills do best - not just answering “how do I turn this on” but also “should I turn this on, given my actual data.”

3. The skills you didn’t touch

Today’s session pulled about half the toolkit. Here’s a fast tour of what the plugin also ships:

Category	Skills	When you’d reach for them
Service shapes	`render-static-sites`, `render-private-services`, `render-background-workers`, `render-workflows`	Frontends on the CDN, internal-only APIs, queue consumers, durable agent pipelines
Data extras	`render-disks`	Persistent storage for a service that needs files (uploads, SQLite, model caches)
Networking	`render-networking`, `render-domains`	Internal hostname conventions, custom domains, TLS
Build / runtime	`render-docker`	Dockerfile-based services, multi-stage builds, image registries
Tooling	`render-cli`, `render-mcp`, `render-migrate-from-heroku`	Scripting deploys in CI, MCP tool reference, Heroku -> Render moves

A useful exercise: pick one and prompt the agent to walk you through it on a hypothetical service. The skills are short, focused, and stand on their own.

4. Beyond skills: the rest of the Render-for-LLMs surface

The plugin is the day-to-day surface. There are three more pieces worth knowing about:

Jules

Jules by Google Labs integrates with Render’s pull request previews. Whenever a preview build fails, Jules detects it, opens its own session, and pushes a fix as a commit on the PR. Setup is on dashboard.render.com/jules. It’s complementary to the editor plugin: the plugin works while you’re at the keyboard; Jules works when you’re not.

Articles as `.md`

Every Render docs page is also available as plain markdown by appending .md:

https://render.com/docs/blueprint-spec
-> https://render.com/docs/blueprint-spec.md

The agent often pulls these directly when it needs a primary source. You can also point your reading agent at https://render.com/docs/llms-full.txt for the whole docs in one file, or https://render.com/docs/llms.txt for an index.

The Inkeep docs MCP

The plugin’s MCP server manages your account. There’s a separate, experimental MCP server for the docs themselves at https://mcp.inkeep.com/render/mcp. Wire it up alongside the main Render MCP for “Ask AI”-style searches over the docs from inside your editor.

{
  "mcpServers": {
    "render": {
      "url": "https://mcp.render.com/mcp",
      "headers": { "Authorization": "Bearer ${RENDER_API_KEY}" }
    },
    "render-docs": {
      "url": "https://mcp.inkeep.com/render/mcp"
    }
  }
}

5. Where to go next

A few directions, ordered by how much they’ll teach you per minute spent:

Run a real failure drill. Have the agent break something else (misnamed env var, wrong healthcheck path, start command typo) and watch which patterns render-debug recognizes. The skills are small enough to read - inspect them under your editor’s skills directory.
Try the same flow in a different editor. The plugin shape is identical across Claude Code, Cursor, and Codex. Doing the loop in two of them is the fastest way to internalize that the skills are the source of truth, not the agent.
Tackle Extend SF Pulse with Render Workflows. It builds an agent pipeline on top of Render Workflows - same plugin, more interesting infrastructure.
Read the Blueprint spec. Now that you’ve seen the agent author one, the spec reads like a reference for tweaking what it generates.

You want to add a Render Key Value-backed leaderboard to tinylink that survives restarts. Which skill is the agent most likely to pull, and which Blueprint construct is the relevant one?

`render-disks` and a `disk:` section on the web service`render-keyvalue` and a `fromService` reference - the existing `tinylink-kv` already has the right semantics`render-postgres` and a new `databases:` entry`render-static-sites` and a `routes:` section

What you learned

Used `/check-render-status` to confirm tinylink is healthy via `render-monitor` and live metrics
Asked the agent about autoscaling and watched it pull `render-scaling` to give context-aware advice
Toured the rest of the toolkit - service shapes, data, networking, build/runtime, tooling - about ~10 skills you can lean on later
Saw the wider Render-for-LLMs surface beyond the plugin: Jules, docs as `.md`, `llms-full.txt`, and the experimental docs MCP

You shipped

You walked an agent through deploy -> break -> debug -> monitor on a real Render workspace, and saw which of the 21 skills it reached for at each step. The plugin isn’t doing anything magical - it’s just shipping the playbooks, rules, slash commands, hooks, and MCP wiring as one bundle so you don’t have to. Now you know what’s in the box.

1. /check-render-status

2. Ask about autoscaling

3. The skills you didn’t touch

4. Beyond skills: the rest of the Render-for-LLMs surface

Jules

Articles as .md

The Inkeep docs MCP

5. Where to go next

What you learned

You shipped

Articles as `.md`