Cogny Sites: Your Agent Can Now Read a Site's Logs and Give It More Memory

Until now, an agent working on a site hosted on Cogny Sites could check the deploy and the environment variables, but not why the site was failing. That needed someone to open a console and read the logs for it.

Two new tools close that gap:

• get_site_logs reads the site's logs: what the running site printed, one line per HTTP request, or a deployment's full build log.
• set_site_resources sets the site's memory and CPU per instance, on the live site, without a rebuild.

Both are on Cogny's MCP server and in the Cogny CLI, and the memory and CPU setting is also a new Resources panel on the site's page in Cogny.

Read the logs

npx @cogny/cli login --api-key <key>
npx @cogny/cli tools call get_site_logs --input '{"site":"owner/repo","level":"error","since":"24h"}'

Pick what to read with source:

Then narrow it down:

• level: "error" keeps errors and anything written to stderr. For requests it means status 500 and up; warning adds the 4xx.
• query keeps only lines containing a text, such as TypeError or /api/checkout.
• since / until take 15m, 6h, 7d or a date and time. Logs are kept for 30 days.
• pr reads a pull request's preview instead of production.
• Up to 200 lines per call, oldest first.

A typical loop: source: "requests", level: "error" shows which paths fail, then level: "error" with a query for that path shows the stack trace, and the fix goes into a pull request whose preview you can check the same way with pr.

Credentials, email addresses and the site's saved variable values are removed from the lines before your agent sees them. Request logs show which pages your visitors open, so reading logs is limited to the workspace's owners and admins, and to workspace API keys, which only they can create.

Give the site more memory or CPU

Every site starts with 512 MiB of memory and 1 vCPU per instance. That's enough for most sites. When it isn't, the site gets restarted mid-request, and visitors see slow pages or timeouts. In the logs it reads:

Memory limit of 512 MiB exceeded

Raise it with one call:

npx @cogny/cli tools call set_site_resources --input '{"site":"owner/repo","memory":"1Gi"}'

• Memory: 512 MiB, 1 GiB, 2 GiB or 4 GiB per instance.
• CPU: 1 or 2 vCPU per instance.
• Applies right away: the live site switches to the new size with no rebuild and no downtime, and every later deploy keeps it. Previews pick it up on their next build.
• get_site shows the current size.
• Cost: a larger size costs more to run, especially for a site kept always warm, so the tool tells agents to check with you first.
• Who: owners and admins, or a workspace API key. People do the same in Cogny under Sites → the site → Resources, and the voice agent can change it too.

More memory buys time; it doesn't explain where the memory goes. After raising it, use get_site_logs to find what grows. For a Next.js site, a common cause is image resizing: each next/image with fill and no sizes prop is resized at full width, and AVIF takes far more CPU to encode than WebP.

Get started

You need an API key for the workspace the site belongs to. Ask its owner or an admin for one (Settings → Data & Integrations → Connect AI Clients). The full reference, with every argument, is in Cogny Sites for agents.