See the release.Understand what happens next.

A project can be healthy while its latest attempted release fails. Fortly keeps that distinction visible: the live application and the new build are separate states. Open a release to see Source, Build and Publish together with its repository, branch, commit and output. The action from Overview opens that release directly, so following a build does not mean searching a general feed for its deployment id.

Build output expands in the selected release. While the build is active, the console polls its retained output every two seconds when the page is visible. Search the output, filter errors, copy or download the lines you need. Scrolling up pauses auto-scroll without stopping incoming updates. Source details remain available alongside the output, making it easier to distinguish a wrong branch from a compiler failure.

A failed release does not replace an earlier live one. The console explains known failure classes and keeps the original diagnostic available. A builder connection problem needs a different response from an application build error. A source-code change will not fix a platform service that cannot be reached. Start with the first meaningful failure, verify the cause and retry after addressing it.

Observability provides Metrics, Logs and Activity for the selected project. Runtime output contains application messages and exceptions. Build and deploy events describe installation and publication. The source, declared level and stream help you focus the feed; writing to stderr alone is not enough to conclude that a line is an application error.

Search can match text across a multi-line entry, and related traceback lines can be expanded as one event. Pause the stream when reading an incident, load older retained events when available, and copy or download the current view. The application-logs action opens runtime output directly; View build stays attached to the chosen release rather than sending you to an unrelated log tab.

Worker logs arrive after a request and its background work finish. The live buffer is bounded, with per-request and per-entry limits documented in the reference. Known project secrets are masked using the platform’s redaction rules, but your application should still avoid logging sensitive data. Download output you need to keep; a live console is not a promise of permanent log retention or a replacement for an external observability pipeline.

Metrics shows project traffic, server errors and response times in a selectable window. Use the chart controls to compare bars and lines, inspect a point and view its underlying data. Keyboard interaction and a tabular view make the graph useful when precise values matter more than the shape. CSV export supports sharing the selected measurements with someone investigating the same incident.

An application with no traffic has an explicit empty state, rather than a decorative success chart. Response-time measurements appear when requests provide data. Shorter windows are kept in memory, and longer history follows the platform’s recorded metrics; restarts and retention affect what is available. The reference explains those boundaries so a blank chart is not confused with proof that nothing happened.

Use Activity to relate project changes to a deployment or investigation. If a Cron Trigger fails, its schedule links to runtime logs. If email is refused, Email Activity names the restriction or provider outcome. Each service keeps its relevant diagnostic close, while the project’s deployment and monitoring workspace gives your team a consistent route back to source, configuration and the release that is actually live.

Open the detailed guide for configuration examples, access requirements, limits and troubleshooting. Then use your own project to verify the full flow before depending on it in production.

Read the monitoring guide · Explore the full platform