For a quick check, query SRS’s HTTP API at /api/v1/summaries; its documentation describes summary data that includes CPU, memory, network and load. For ongoing collection and dashboards, use the SRS Prometheus exporter, scrape it with Prometheus, and add node_exporter to see the host as well as the SRS process.
The exact fields and setup depend on your installed SRS release and configuration. Start with a local API check, then confirm the version-specific documentation before building monitoring around it. A single snapshot is useful for diagnosis, but it is not a history of what happened overnight.
Check the SRS version first
Before copying an endpoint or exporter configuration, identify the SRS release actually running. SRS documentation is versioned, and the material for v4, v5, v6 and v8 does not establish that every route, field or default behaves identically across releases. The exporter guide, for example, says its documented usage applies to SRS 5.0.86 or later; treat that as the scope of that guide, not a general guarantee about every SRS build.
Check the binary or package information using the method appropriate to how you installed SRS. If you built it from source, inspect the release or build information for that checkout; if it is managed by a container or package, inspect the image tag or package version rather than assuming it tracks the latest documentation. Record the version alongside any monitoring notes so a later upgrade does not silently invalidate your assumptions.
The docs themselves also need reading with care. The v8 API reference is marked unstable. The v6 introduction contains both a stable label and a development-status note. Those signals are reasons to verify the documentation matching your deployment, not to infer that one endpoint’s details are settled for all releases. The SRS HTTP API reference is a useful starting point, but follow its version context and compare it with your installed release.
If you are already troubleshooting a busy encoder, keep application and host observations separate. A process can look modest while another workload saturates the machine, or the machine can have spare capacity while the SRS process is constrained by its own settings. For a complementary discussion of the local-encoding side, see how CPU and RAM affect a 24/7 FFmpeg stream.
Make a quick summaries request
SRS exposes an HTTP API for system and stream information. A first check is a request to /api/v1/summaries. The v5 documentation shows the API on port 1985, and the v4 reference lists summaries among its API endpoints. A local example is:
curl http://127.0.0.1:1985/api/v1/summaries
This assumes that the API listener is enabled and bound where the command can reach it. If SRS runs on another machine, substitute an address reachable from your monitoring machine, but do not expose an administrative API port directly to the public internet merely to make the test convenient. Restrict access according to your network arrangement, and check the configuration and documentation for the installed release.
The response is structured data rather than a ready-made monitoring screen. Inspect it in the terminal first; if your shell has a JSON formatter, piping the response through it can make the fields easier to scan. A failed request is not proof that SRS has no system statistics. Check that the API is enabled, that the address and port are correct, and that a firewall or container network is not blocking the connection.
This endpoint is best treated as a point-in-time inspection or the basis of a small custom check. It does not, by itself, provide a retained time series or an alert when a value changes later. If you need to know whether memory rose steadily during the night, collect metrics periodically and store them in a monitoring system instead.
A simple one-off check can help distinguish a stream problem from a process or host problem. Compare the returned values with the time an issue occurred, and note whether the channel was idle, actively sending media, or serving a busy period. Avoid turning one reading into a universal pass/fail threshold: the source material does not publish a safe CPU or memory cutoff for all SRS deployments.
Read the figures in context
The SRS documentation describes summary information covering memory, CPU, network and load. The exact fields in the response can depend on version and configuration, so first establish what your own response actually contains. Do not assume a field absent from one release is an error, or that every statistic is active just because the API returned a summary object.
CPU and memory readings help answer different questions. CPU observations can indicate that work is consuming processor time, but a brief increase while starting or changing a stream is not the same as sustained saturation. Memory observations need a time context: a stable allocation during a long run has a different operational meaning from a value that keeps rising. Correlate a concern with stream quality, process behaviour and host capacity rather than applying a threshold borrowed from another machine.
Network and load figures likewise need interpretation, not just collection. A reported network value is not a substitute for checking the path between your server and YouTube when the stream drops. Load offers host context, but its meaning depends on the system and the number of available processors. Use the values to ask what changed and when, then compare them with a known healthy period for the same channel and machine.
SRS’s v4 API documentation describes a stats configuration for system statistics and points to CPU and memory, with network and disk statistics also configurable. It notes that stats.network relates to heartbeat system reporting and identifies disk-statistics configuration. This is version-specific guidance; verify the configuration syntax and behaviour in the documentation for your release before editing it. An endpoint responding successfully does not establish that every optional statistic has been enabled.
For a useful baseline, record a few representative operating conditions: stream start, steady operation, and a period when viewers or other workloads are active. The point is not to create a formal benchmark, but to learn what normal looks like on this installation. When an overnight issue occurs, compare the same measurements with stream quality and timing; a single CPU percentage without that context rarely tells you what to change.
Use focused resource endpoints when needed
The API reference lists additional endpoints for more specific views: /api/v1/rusages, /api/v1/self_proc_stats, /api/v1/system_proc_stats and /api/v1/meminfos. They may be helpful when a summary does not answer the question—for example, when you need a more focused process or memory view. Consult the matching release’s reference before scripting against them; the presence and shape of an endpoint in one version should not be assumed unchanged in another.
A practical sequence is to begin with summaries, note which value is unclear, and then consult a focused route only for that question. If you need process statistics, distinguish the SRS process from system-wide data. If you need memory detail, check whether the relevant system statistics are configured and whether the returned data corresponds to the process or the host. Avoid building a dashboard around undocumented assumptions about field names.
For recurring use, a script that polls the API can be enough for a small, private integration, provided you handle failed requests and avoid exposing the listener. But a script that merely prints values still leaves you responsible for retention, graphing, alert rules and failures in the script itself. Once those needs grow, the documented exporter path is more appropriate than repeatedly extending an ad hoc command.
Choose snapshots or ongoing collection
The main choice is whether you need an answer now or a record over time. An API snapshot is quick to request and needs little surrounding software. It is suited to checking a suspected issue or fetching a value for a limited integration. It does not retain the past unless you build that collection and storage yourself.
Prometheus collection adds setup and dependencies, but it gives you a time series to inspect later. Grafana can render that history as dashboards. The SRS exporter guide’s example also scrapes node_exporter separately, because SRS-specific observations and whole-host observations are related but not interchangeable.
| Approach | Best use | What it shows or adds | Main caveat |
|---|---|---|---|
SRS /api/v1/summaries |
Immediate check or small integration | A snapshot of documented summary information | Version, listener and statistics configuration affect what you can retrieve; it does not create history by itself. |
| SRS Prometheus exporter | Repeated collection of SRS metrics | Metrics that Prometheus can retain and query | Confirm the exporter instructions apply to your SRS release and configuration. |
| node_exporter with Prometheus | Machine-level context | Host metrics collected as a separate target | It complements SRS observations; target addressing and host/container visibility depend on deployment. |
| Grafana | Exploring and presenting collected data | Dashboards built from a configured data source | It visualises collected metrics; it does not collect them on its own. |
If all you need is to check whether the API responds, adding Prometheus and Grafana is unnecessary work. If you need to find a gradual change that began hours earlier, a snapshot cannot answer that without a collector and a place to retain results. The SRS exporter guide shows the ongoing-collection approach; read its version note before using its settings.
Set up Prometheus collection
The documented exporter path has three main jobs: SRS exposes metrics, Prometheus scrapes and stores them, and Grafana can visualise the stored metrics. In the SRS v8 exporter guide, the exporter is off by default and the documented default listener is port 9972. Environment variables are used in that guide to enable and configure it. Those details belong to that guide and its stated SRS 5.0.86-or-later scope; do not copy them blindly to an older or differently configured installation.
Enable the exporter using the method documented for your deployment. Confirm that the listener is reachable from the Prometheus process, but keep it on a protected network and avoid publishing monitoring interfaces unnecessarily. Verify the exporter with a local or otherwise restricted request before adding a scrape target. If the listener is not reachable, check the bind address, port mapping, firewall and the network view from the Prometheus host.
Prometheus uses a configuration file to define scrape jobs. The SRS guide provides an example with separate jobs named srs and node, and a five-second scrape interval. That interval is the guide’s example, not a universal recommendation. Choose a collection frequency that suits your monitoring purpose and operating constraints, and retain the association between each job and its target so that SRS readings are not confused with host readings.
A simplified shape of the guide’s configuration is shown below. Treat it as an illustration of separate targets, not a drop-in file: use the actual addresses and ports visible from your Prometheus instance, and validate the syntax against the Prometheus version you run.
scrape_configs:
- job_name: srs
static_configs:
- targets: ['srs-host:9972']
- job_name: node
static_configs:
- targets: ['node-host:9100']
The exporter guide’s example configuration includes a scrape interval of five seconds. If you use that setting, attribute it to the example rather than presenting it as a required SRS setting. A slower interval may be adequate for a channel where you are looking for sustained trends; faster collection can produce more data and is not automatically more useful. Choose based on the questions you need to answer and verify the results after deployment.
After reloading or starting Prometheus, confirm that both targets are being scraped successfully before relying on their graphs. If SRS metrics appear but node metrics do not, investigate the node_exporter target separately. A healthy SRS target only establishes that Prometheus can reach the exporter; it does not prove that the values mean what you expect or that the host is unconstrained.
Add host metrics and a Grafana view
The SRS exporter example pairs the SRS target with node_exporter. That distinction matters when diagnosing an overnight stream: SRS metrics describe the media-server perspective, while node_exporter is included to collect data about the node. If the machine is short of memory or busy with another workload, looking only at the SRS summary can leave out useful context.
Install and configure node_exporter according to its own documentation and your operating environment, then make it reachable from Prometheus. The SRS example uses a separate node scrape job; it does not establish one networking recipe for every virtual machine, container or cluster. In Docker or a cluster, check what address Prometheus can actually resolve, whether the relevant port is published or routable, and whether the exporter sees the host or only a container’s environment. The Prometheus project documentation explains the collection model, while deployment-specific network settings still need to match your environment.
Once Prometheus is collecting both targets, connect Grafana to Prometheus as a data source and build a small view around the questions you actually ask. Start with separate panels for SRS and host observations, with labels that make the target clear. Add time ranges that let you compare a problem window with normal operation. The graph should make it easier to correlate a change with stream behaviour, not imply that a single number is a universal health score.
If you run several channels or machines, keep names and labels consistent enough to identify the stream and host. A graph labelled only “CPU” can be misleading when it is unclear whether it reflects the SRS process, the node, or another target. Test the dashboard by generating a known change or comparing it with the live API and host observations; do not assume that a visually populated panel is querying the intended metric.
Monitoring also needs basic operational care. Decide how long you need to retain data, who can access dashboards, and what should happen when a target stops reporting. A missing series may mean an exporter or network problem rather than zero resource use. Keep the monitoring endpoint and dashboard access restricted in line with your server’s security arrangements.
The pattern helps you make a measured diagnosis: use SRS data to understand the stream process, host data to understand the machine, and the timeline to see whether either changed alongside the incident. If you are planning a continuous channel rather than troubleshooting an existing server, it is also useful to understand how a playlist can run in YouTube Live Control Room and what an overnight Punjabi music stream needs. Those are operational choices, not substitutes for confirming your own SRS monitoring setup.
Keep the monitoring useful
Begin with the smallest check that answers your current question. For a suspected high-memory event, fetch summaries and note the time; if the result is unclear, check the relevant focused endpoint where supported. For a recurring pattern, deploy collection and compare SRS and node observations. This sequence avoids maintaining a dashboard stack when an occasional inspection is enough, while still giving you a route to retained evidence when a one-off response cannot explain the problem.
Do not treat any reading as a promise of stream quality. A process can report ordinary resource use while the uplink is unstable, and a host can appear busy for reasons unrelated to YouTube delivery. Correlate monitoring data with the stream’s own status and the times viewers reported a fault. For network-specific troubleshooting, see the guide to a YouTube Live network error on a VPS.
When you change SRS versions, revisit the API and exporter documentation rather than assuming a configuration that worked before still applies. Keep a short record of the release, enabled statistics, scrape targets and dashboard queries. That makes a later incident easier to compare and helps you identify whether a missing metric came from a version change, a configuration change or a broken target.
If the problem you are trying to remove is keeping a computer running just to send a fixed video continuously, StreamNeo removes that specific need: you upload the file and provide your YouTube stream key, then the broadcast can run with your computer switched off. It is YouTube-only, so it does not replace SRS monitoring for a self-managed server or provide a general-purpose SRS dashboard.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does /api/v1/summaries show historical CPU and memory usage?
No. Treat it as an API request for current summary information, not a historical dashboard. To examine changes over time, collect metrics with the SRS exporter and Prometheus, then visualise the retained data in Grafana if useful.
Why is the summaries request failing?
Check that the HTTP API is enabled, that you are using the correct host and port, and that the request can reach the listener from where you run it. Also confirm the API route against the documentation for your installed SRS version; do not expose the API publicly just to make the request work.
Do I need node_exporter if SRS already reports resource use?
Not necessarily for a one-off SRS check. The SRS exporter example adds node_exporter as a separate target to provide host context, which can help distinguish process-level observations from machine-level capacity or competing workload.
Is the exporter configuration the same for every SRS release?
No. The exporter guide has a stated release scope, and the API references differ by version. Check the matching documentation and validate the listener, fields and configuration against the SRS release you have installed.