Logs & monitoring

Once your app is online, the next question is always the same: what is it actually doing right now? Logs are how you find out. Think of them like a diary the app keeps: every time it starts, prints a message, or handles a visitor, it writes a line. When something goes wrong, that diary is the first place to look.

Synq gives you two kinds of diary and one big-picture view:

• Runtime logs: what your app itself prints (startup messages, errors, console.log). This is what you want when the app is crashing or misbehaving.
• Request logs: a line for every web request that reached your app: who asked, for what page, and what answer they got. This is what you want when you're asking "is anyone visiting?" or "why are people getting errors?"
• Analytics: the same request data rolled up into totals and a traffic chart, so you can see trends instead of individual lines.

Open the Logs tab

Runtime logs: the Terminal sub-tab

The Terminal sub-tab is a live view of everything your app prints while it runs: the same output you'd see in a terminal if the app were running on your own machine. If your code calls console.log, throws an error, or prints a startup banner, it shows up here.

A few things worth knowing:

• It streams by itself. When you open the tab it starts tailing new lines automatically. A small green dot and a Stop button tell you it's live; press Stop to freeze it, Start to stream again.
• Search. There's a search box at the top: type to highlight matches, press Enter / Shift+Enter to jump between them.
• Copy, Download, Clear. The buttons on the right let you copy the visible logs to your clipboard, save them to a .txt file, or clear the view.

Search past logs: History

The live tail only shows what arrives while you watch. To look back, switch the Live / History toggle at the top of the Terminal sub-tab to History. It searches what the container already wrote:

• Time range: the last 15 minutes, hour, 6 hours, 24 hours or 7 days, or a Custom range with a start and an optional end.
• Stream: both, only stdout, or only stderr (where most apps print their errors).
• Level: error, warning, info or debug. Synq detects the level per line on a best-effort basis: a JSON level / severity field (including pino's numeric levels), level=warn pairs, markers like [ERROR], or upper-case words like WARN. Lines with no marker only show up under All levels.
• Text: a case-insensitive filter, applied on the server.
• Service: in a multi-service project, the same Runtime log target picker chooses which service to search.

Press Load to run the query and Download to save exactly the filtered result as a .txt file. A query returns at most the newest 5,000 matching lines; when more matched, a note says so and you can narrow the range. Filtered queries (a stream, level or text filter, or an end time) search the newest 100,000 lines the container kept, and say so when older lines in the range were not searched.

Request logs: the Server sub-tab

The Server sub-tab (titled HTTP Request Logs) shows one line for every web request that reached your app. Each line tells you:

• the method (GET, POST, …) and the path that was requested,
• the status code the app sent back (green for 2xx, blue for 3xx, amber for 4xx, red for 5xx),
• how long it took (response time in milliseconds),
• the visitor's IP address and country, the bytes in and out, and their browser (user agent).

Like the Terminal, this view is live: new requests appear at the top as they happen.

If your project answers on more than one domain, a domain switcher appears in the header so you can look at one domain's requests at a time.

The bigger picture: analytics

Individual request lines are great for "what just happened," but for "how's it doing overall" you want the rollup. Open the project's Overview tab and you'll see it:

• Stat cards across the top: Server Requests, Unique IPs, Avg Response (average response time), and Bandwidth Out.
• A Traffic chart showing requests over time.
• A Top Paths list: the pages and endpoints getting the most hits.

This is the same request data as the Server sub-tab, just counted up. Empty at first, it fills in as traffic arrives.

For more depth, open the project's Monitoring tab: live CPU and memory, a traffic panel with requests in flight, error rate and p50/p95/p99 latency, a visitor map, and the container Health history. See App monitoring. For every app and server at once, use the Monitoring page in the sidebar.

Where to look when something is wrong

A quick map so you don't have to guess:

• The app won't start, or it's crashing → Logs → Terminal. Read the last lines; the error is almost always right there.
• Visitors are getting errors → Logs → Server. Look for red (5xx) lines, note the path, then check the Terminal for the matching stack trace.
• "Is anyone even using this?" → Overview analytics, or the Monitoring tab for detail.
• "Is the server itself struggling?" → the server's Overview tab or the Monitoring page (see Server monitoring and alerts).
• The deployment itself failed (it never went live) → open that deployment from the Deployments tab and read its build log; that's a separate stream from the runtime logs above.

CLI

Everything above is available from the CLI too. First grab your project's ID with synq project list, then:

# Runtime (container) logs: what your app prints
synq project logs <project-id>              # recent lines
synq project logs <project-id> --tail 200   # last 200 lines
synq project logs <project-id> -f           # follow / stream live

# HTTP request logs: every web request that hit the app
synq project server-logs <project-id>                 # recent entries (JSON)
synq project server-logs <project-id> --limit 200     # up to 200 entries
synq project server-logs <project-id> --domain yourapp.com   # one domain only
synq project server-logs <project-id> -f              # stream live

# A specific deployment's build/run log (grab the id with: synq deployment list)
synq logs <deployment-id>          # snapshot
synq logs <deployment-id> --tail 100
synq logs <deployment-id> -f       # stream until the deployment finishes

The same history search is available over the API at GET /projects/<project-id>/logs/history, with the query parameters since and until (relative like 15m, 1h, 24h, 7d, or an ISO date), stream (stdout, stderr or both), level (one or a comma list of error, warn, info, debug), q (text), service (a service id or name) and tail (up to 5000). Each returned line carries its timestamp, stream, detected level (when there is one) and text.

Troubleshooting

Related guides