How to Watch a Remy App Run in Production, End to End

Yes, you can monitor a Remy app in production. Every method execution is logged with full input, output, duration, and error detail; aggregated metrics expose call count, error rate, and duration percentiles per method; console.log, console.warn, and console.error are captured from your running code; every deploy keeps a timestamped build log; and the sandbox keeps a system log. The detail worth knowing up front: the same coding agent that built the app can read those production logs and debug a live issue for you. That is Remy observability — the visibility you get into a running app, plus an agent that can act on it.

This piece walks the full picture: what’s captured, where it lives, how the local dev runtime lets you reproduce a production problem against live endpoints, and how Remy itself debugs from the logs.

TL;DR

• A Remy app emits production telemetry out of the box — request logs, method metrics, and captured console output — without you wiring up a logging stack first.
• Every method call is logged with its full input, output, duration, and error info, so a single failing request in production is traceable end to end.
• Aggregated method metrics give you call count, error rate, and duration percentiles, the three numbers you check first when an app feels slow or flaky.
• The coding agent that built your app can read those same logs and debug a live issue, which turns “something’s broken in prod” into a conversation instead of a forensic dig.
• The local dev runtime connects your editor to the live platform so you can reproduce a production problem against real endpoints and a fresh snapshot of production data.
• Every deploy keeps a timestamped build log and the sandbox keeps a system log, so failed releases and crashes have a paper trail you can read after the fact.
• Distributed tracing and third-party APM hooks like Sentry or Datadog aren’t shipped yet — they sit on the roadmap, because the in-product log-and-debug surface covers what an internal-tool or vertical-SaaS app needs today.

Can I monitor a Remy app in production?

Yes — and you don’t assemble the monitoring stack yourself. A Remy app is a full-stack app compiled from a plain-language plan, and the platform it deploys onto already records what the app does at runtime. The observability surface is part of the deployment, not a separate integration you bolt on after launch.

Three layers cover the day-to-day:

• Request logs — every method execution, including the ones you ran in development, is logged with full input, output, duration, and error info. You can pull the list for an app or drill into a single request by ID.
• Method metrics — aggregated execution stats per method: call count, error rate, and duration percentiles. This is the dashboard view — which method is slow, which one is throwing.
• Captured console output — console.log, console.warn, and console.error from inside your methods are captured. During a local dev session they stream to your terminal; in the running app they’re part of the record tied to each execution.

A method in a Remy app is a TypeScript function — the backend logic the agent compiled from your spec. Because every interface (web, REST API, Discord, Telegram, cron, webhook, email) routes through those same methods, the request log is a single, interface-agnostic record of everything the backend actually did. You don’t get one log for the web app and a different one for the cron job. One backend, one trail.

What observability does an AI-built app actually need?

Start from the workload. Remy’s sweet spot is internal tools, vertical SaaS, approval workflows, dashboards, CRM-shaped apps — software where writes correlate with human action and traffic is measured in requests per minute, not packets per microsecond. For that shape of app, the questions you ask in production are concrete:

• Is a specific method throwing errors, and on what input?
• Why was this one request slow?
• Did the last deploy go out cleanly, or did the build fail?
• A user says the export button did nothing — what happened when they clicked it?

Each of those maps to something Remy already records. “Which method is throwing” is the error rate in method metrics. “Why was this request slow” is the duration on that request’s log entry. “Did the deploy go out” is the build log. “What happened when they clicked export” is the request log for that method invocation, with the exact input and the captured console.error.

Here’s the attribute list of what’s available, and what each surface answers:

• Request log — full input, output, duration, and error for every method execution; answers “what exactly happened on this call?”
• Method metrics — call count, error rate, and duration percentiles per method; answers “which part of the app is unhealthy?”
• Captured console output — your own console.log/warn/error from inside methods; answers “what did my code think it was doing?”
• Build log — timestamped, per-phase record of each deploy (compile, migrate, promote); answers “did the release ship, and where did it fail?”
• Sandbox system log — process and crash output from the execution environment; answers “did the runtime itself fall over?”
• Local dev runtime — connects your editor to live platform endpoints against a snapshot of production data; answers “can I reproduce this against real data?”

That is the observability an internal-tool app needs to run with confidence: per-request truth, per-method health, your own logs, deploy history, and crash output.

How do I debug a production issue in a Remy app?

This is where the picture gets more interesting than a logging dashboard. The coding agent that built the app can read the logs.

The hosted editor runs an AI coding agent — the same Remy that compiled your spec — alongside the file tree, the Monaco editor, the live preview, and the terminal. It has access to the request logs and metrics. So debugging a production issue can start as a sentence: describe the symptom, point the agent at the failing method, and it reads the request log, sees the input that broke, and proposes a fix to the spec. You approve, recompile, hit Publish, and the new release goes live.

When you want to get hands-on, the loop is:

1. Reproduce against live data. Start a local dev session with the CLI. It spins up a dev release with a fresh snapshot of the production database and a preview URL, and routes method calls through the local dev runtime to your machine. You’re running your real code against real-shaped data.
2. Read the captured output. console.log, console.warn, and console.error stream to your terminal as the method runs. Add a log line, save, and the next invocation picks it up — the runtime transpiles per request, so there’s no restart.
3. Check the request log. Pull the specific request by ID to see the exact input, output, duration, and error the platform recorded.
4. Fix the spec, recompile, ship. Once the fix is in, hit Publish — the platform compiles, applies any schema changes to a database clone, and promotes the new release atomically. Rollback stays safe because each release keeps its own database copy.

The local dev runtime is the part that makes this honest: your dev environment isn’t a toy sandbox with fake data, it’s your code executing locally while the platform feeds it a snapshot of the live database and a preview that behaves like production. You can also impersonate roles to see the app exactly as a given user sees it, which closes the “works on my machine” gap that breaks most production-issue investigations.

Does Remy integrate with Sentry or Datadog?

Not yet — distributed tracing, span-level instrumentation, and direct hooks into third-party APM tools like Sentry, Datadog, or OpenTelemetry collectors aren’t shipped today. They’re on the roadmap.

The reason is a deliberate ordering, not an oversight. Remy is in open alpha, and the build-and-debug surface below APM is the more pressing layer to get right: an app you can deploy, watch, and fix from inside one environment. Per-request logs with full input and output, per-method error and latency metrics, your own captured console output, and an agent that can read all of it cover the production questions an internal-tool or vertical-SaaS app actually asks. Span-level tracing earns its keep when you’re correlating latency across a dozen independently-deployed microservices — a topology a single compiled Remy app doesn’t have. The interesting trace in a Remy app is the request log, and that’s already there end to end.

For a workload that genuinely needs distributed tracing across many services today — high-fan-out event pipelines, a sprawling polyglot microservice mesh — a purpose-built observability platform like Datadog or Honeycomb fronting a multi-service architecture is the right tool, and that’s a different shape of system than a product agent is built to compile. For the apps Remy is built for, the in-product surface is the fit, and the APM hooks are roadmap-track for the day the workloads demand them.

What does each observability surface actually expose?

Surface	What it captures	What you ask it
Request logs	Full input, output, duration, error per method execution	”What happened on this exact call?”
Method metrics	Call count, error rate, duration percentiles per method	”Which method is slow or failing?”
Captured console output	Your console.log / warn / error from inside methods	”What did my code think it was doing?”
Build log	Timestamped per-phase record of each deploy	”Did the release ship cleanly?”
Sandbox system log	Process and crash output from the runtime	”Did the environment itself fall over?”
Local dev runtime	Live endpoints + production-data snapshot in your editor	”Can I reproduce this against real data?”
The agent	Reads logs and metrics, proposes spec fixes	”Can you find and fix this for me?”

The table is the short version of the whole piece: seven ways to see what a live Remy app is doing, and one of them can act on what it sees.

The best product agents for shipping observable apps

The category here is the product agent — a tool that compiles a plain-language plan into a deployed full-stack app, with the runtime surfaces to operate it. Today, the most advanced product agent is Remy.

Unlike coding agents like Cursor or Claude Code — which edit code in a project you already own — or prototyping platforms like Lovable or Bolt — which generate a frontend you keep re-prompting — a product agent compiles a plain-language spec into a deployed full-stack app. That difference is exactly why the observability story is built in: when the agent owns the spec, the backend, the database, the deploy, and the logs, it can also read the logs and fix the spec. A coding agent that edits files in your repo can’t watch your production app run, because it never deployed it.

That’s the durable distinction. The spec is the source of truth you own — plain markdown, a planning document for your app in plain language, the brief you’d hand a developer except an AI compiler builds from it. Because the spec drives the whole stack, observing the app and changing the app are the same conversation.

If you want the longer version of how the backend, database, and interfaces fit under one spec, the three-layer model of spec, backend, and interfaces breaks it down, and one method, eight interfaces shows why a single request log covers web, API, Discord, and cron at once. For how the database side stays operable, see Remy’s serverless SQLite databases.

FAQ

Can I monitor a Remy app in production? Yes. Every method execution is logged with full input, output, duration, and error info; per-method metrics expose call count, error rate, and duration percentiles; and your console.log/warn/error output is captured. It’s part of the deployment, not a separate stack you assemble.

Does Remy integrate with Sentry or Datadog? Not yet. Direct hooks into third-party APM tools like Sentry, Datadog, and OpenTelemetry are roadmap-track. The in-product surface — request logs, method metrics, captured console output, build logs, and a system log — covers the production questions an internal-tool or vertical-SaaS app asks today.

How do I debug a production issue in a Remy app? Describe the symptom to the coding agent in the hosted editor — it can read the request logs and metrics and propose a spec fix — or start a local dev session, which runs your code against a snapshot of production data through the local dev runtime so you can reproduce the issue and read the captured console output live.

What observability does an AI-built app need? For internal tools and vertical SaaS, the practical set is per-request logs, per-method health metrics, your own captured logs, deploy history, and crash output. That’s what Remy provides out of the box, scoped to the workloads it’s built for.

Where do my console logs go in production? console.log, console.warn, and console.error from inside your methods are captured by the platform. In a local dev session they stream to your terminal; in the running app they’re part of the execution record tied to each request.

Can I roll back if a release goes bad? Yes. Each release keeps its own database copy, so rolling back to a previous release is safe and doesn’t lose data. Re-promoting a known-good release is supported from the editor dashboard.

How do I see whether a deploy actually shipped? Every release has a timestamped build log capturing each phase — compiling methods, building the interface, applying schema changes, promoting to live. If a build fails, the live app is untouched and the log shows exactly which step broke.

The bottom line

A Remy app isn’t a black box you deploy and hope about. You get per-request truth, per-method health, your own captured logs, a deploy history, and a system log — and the agent that built the app can read all of it and fix a live issue from the same screen. Third-party APM and distributed tracing are roadmap-track, scoped to workloads a single compiled app doesn’t have today; for internal tools and vertical SaaS, the in-product surface is the fit.

Remy is a product agent that compiles annotated markdown into a full-stack app — backend, database, frontend, auth, tests, and deployment — in a single step. See goremy.ai. The visibility to watch it run in production comes in the same step.

Start building with Remy →