Project Monitoring
Use project-wide monitoring to review the health, metrics, and logs of every service in a project from a single observability surface.
The Monitoring page gives you a unified observability window across every app and database in a project. Instead of opening each service individually, you can correlate events, trace issues, and assess overall project health from one place.
What Project Monitoring Shows
Service Health
A real-time status summary for all apps and databases in the project — running, degraded, restarting, or stopped. Spot at a glance which services need attention.
Resource Metrics
CPU, memory, and network usage aggregated across the entire project, with per-service breakdowns. Understand which services are under pressure and which are over-provisioned.
Aggregated Logs
A combined log stream from all services in the project. Filter by service, severity, or keyword to find the event you are looking for without switching between individual app views.
Deployment History
A timeline of recent deployments across all apps — who deployed what, when, and whether it succeeded. Use this to correlate a service degradation with a recent change.
When to Use Project Monitoring
Project-level monitoring is most valuable when a problem is not obviously isolated to a single service.
Use project monitoring to:
- Determine whether a slowdown in one app is caused by a dependent service in the same project.
- See if multiple services degraded at the same time — which often points to a shared infrastructure issue rather than a per-service bug.
- Review which service is consuming disproportionate CPU or memory when project costs increase unexpectedly.
- Get a high-level health snapshot before a release or during an incident.
Then drill into app-level monitoring when you have identified which service needs deeper investigation. Each app has its own dedicated log viewer, metrics timeline, and deployment detail.
Reading the Aggregated Log Stream
The project log stream combines output from all running services. By default, logs from all sources are interleaved in chronological order.
Use filters to narrow the view:
- Service filter — show logs only from a specific app or database.
- Severity filter — show only errors, warnings, or informational messages.
- Keyword search — find a specific trace ID, error message, or request path across all services.
Logs are retained for a rolling window defined by your plan. For longer retention or external log forwarding, configure log export from the individual app settings.
Correlating Issues Across Services
A common scenario: users report errors, but the problem is not in the app they are visiting — it is in an internal API that app depends on.
In project monitoring:
- Open the aggregated log stream and look for error spikes.
- Note which services produced errors at the same time.
- Check the deployment history to see if any of those services were recently updated.
- Open the affected service directly to investigate.
This cross-service correlation is the primary reason to start at the project monitoring level rather than jumping straight into individual app logs.
Related
- Project Overview — understand what resources live inside a project.
- Project Usage — track resource consumption and cost across the same project.
- Apps Overview — manage and monitor individual apps.
How is this guide?