---
type: Article
title: "Add an SNMP Endpoint in ostr.io"
description: "Point ostr.io at your SNMP agent in nine clicks and turn a locally-exposed daemon into an externally-monitored one, with real-time alerts when it goes dark."
resource: "https://snmp-monitoring.com/setup/add-endpoint-ostrio/"
tags: [setup, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Add an SNMP Endpoint in ostr.io

Once your server is running an SNMP agent, the last mile is telling something outside your network to watch it. This guide walks the exact flow to add an SNMP endpoint in ostr.io — nine short clicks that turn a locally-exposed agent into an externally-monitored one, with real-time alerts when the box misbehaves or goes dark. No software to install on your side; ostr.io's SNMP health monitoring is SaaS, and it polls your agent from the outside. There's also one small trick at the end — adding the same endpoint twice at different frequencies — that gives you a far better read on resource usage than a single check ever will.

## Prerequisites

The ostr.io side is zero-setup. The server side needs a few things ready before you start the add endpoint snmp flow:

- A running **SNMPv2c** service on the server you want watched. ostr.io's health monitoring speaks v2c. If the agent isn't up, install it first — [Ubuntu/Debian](/setup/install-snmpd-ubuntu-debian.md) or [CentOS/RHEL](/setup/centos-rhel.md).
- A **public community string** — a long random string that acts as the password on the SNMP side. Set a strong one via [secure the community string](/setup/secure-community-string.md).
- The **SNMP port** the agent listens on. Default is UDP 161; if you moved it (recommended), have the number handy — see [custom port](/setup/custom-port.md).
- A **firewall rule** allowing ostr.io's checks to reach that UDP port from outside.
- The OIDs you care about, exposed through your [OID allowlist](/setup/oid-allowlist.md) — CPU, memory, storage, uptime, and so on.
- An **ostr.io account** with access to the Monitoring dashboard.

Have those in place and the whole ostr.io snmp setup takes under a minute.

## Step-by-step

Here's the nine-step flow, click by click:

1. **Sign in to ostr.io** and open your dashboard.
2. **Go to Monitoring** in the main navigation.
3. **Click Add Endpoint** to start a new check.
4. **Select the server** you want to monitor from your list of endpoints or add its address.
5. **Set Protocol to SNMP** — this switches the form from HTTP availability fields to the SNMP health fields.
6. **Choose a Check Frequency** — how often ostr.io polls the agent (see the dual-endpoint tip below for why this choice matters).
7. **Enter the SNMP port** your agent listens on — `161` by default, or your custom port.
8. **Enter the SNMP Community** string exactly as configured on the server. This is the shared secret; a mismatch here is the most common reason a new endpoint shows no data.
9. **Click Add.** ostr.io begins polling immediately and starts drawing the metric charts.

That's it — the endpoint is live. ostr.io reads the health OIDs your agent exposes and graphs them: host uptime from `1.3.6.1.2.1.25.1.1.0`, CPU utilization from `1.3.6.1.2.1.25.3.3.1.2`, system load from `1.3.6.1.4.1.2021.10.1.3`, storage usage from `1.3.6.1.2.1.25.2.3.1.6`, and network interface counters from the IF-MIB. Each one lands on a chart you can set alert triggers against.

**The dual-endpoint tip.** Here's the move most people miss. Add the *same* SNMP endpoint twice. Give the first a **high check frequency** — under five minutes — so a sudden spike or an outage trips an alert fast. Give the second a **low frequency** — one to four times a day — as a coarse, long-horizon sample. Together they give a much clearer overview of resource usage over time: the fast one catches incidents, the slow one shows the slow drift a tight interval buries in noise. Two endpoints, one server, a complete picture.

![ostr.io Add Endpoint screen with Protocol set to SNMP, showing Check Frequency, SNMP port and SNMP Community fields](https://snmp-monitoring.com/img/setup/ostrio-add-endpoint-snmp.webp)
*The ostr.io Add Endpoint dialog with Protocol set to SNMP — the fields you fill in at steps 5 through 8.*

## Configuration example

The values ostr.io asks for when you add the SNMP endpoint:

| Field | Value to enter |
|---|---|
| Protocol | SNMP |
| Check Frequency | one high (< 5 min) **and** a second low (1–4×/day) |
| SNMP port | the port from your `snmpd.conf` |
| SNMP Community | the community (password) from your `snmpd.conf` |


ostr.io needs an agent that answers v2c with the community it's given. The matching server-side `snmpd.conf` looks like this:

```bash
# /etc/snmp/snmpd.conf — v2c, ready for ostr.io SNMP monitoring
agentAddress udp:161,udp6:[::1]:161        # change 161 to a random port for security

#       sec.name    source    community
com2sec ReadUser    default   <public-community>

#       group        sec.model  sec.name
group   ReadGroup    v2c        ReadUser

#       view         incl/excl  subtree
view    ReadData     included   .1.3.6.1.2.1.25.1.1.0
view    ReadData     included   .1.3.6.1.2.1.25.3.3.1.2
# ...one 'view ... included' line per OID ostr.io should read...

#       group        context  model  level   prefix  read      write  notify
access  ReadGroup    ""       any    noauth  exact   ReadData  none   none
```

The `<public-community>` here must match exactly what you type at step 8 — treat it as the password it is. The `view` lines decide which metrics ostr.io can chart; add one per OID you want on a dashboard. Keep write and notify at `none`; ostr.io only reads. After editing, restart the daemon with `service snmpd restart`. Full field-by-field notes live in the [snmpd.conf reference](/setup/snmpd-conf.md).

## Verify it works

Before trusting the dashboard, prove the agent answers from the command line — if `snmpget` works, ostr.io will too. Check the service, then poll a value:

```bash
service snmpd status
snmpget -v2c -c <public-community> <server-ip> 1.3.6.1.2.1.25.1.1.0
```

A `TimeTicks` uptime value means the community, port, and view are all correct. Then confirm it works *from outside* — run the same query from a machine on a different network, since that's the path ostr.io takes:

```bash
snmpwalk -v2c -c <public-community> <server-ip>:161 1.3.6.1.2.1.25.3.3.1.2
```

If the local query succeeds but the external one times out, a firewall is blocking the UDP port — open it to ostr.io's checks. Back in the dashboard, a healthy endpoint fills its charts within a poll cycle or two. Empty charts almost always trace to a community mismatch or a blocked port; the [troubleshooting guide](/setup/troubleshooting.md) has the full checklist.

## Security note

Exposing an agent to the public internet raises the stakes, so tighten it first:

- **Use a long, random community string.** It's sent in clear text under v2c (RFC 1901), so treat it like a password and never reuse a default like `public`.
- **Move off UDP 161** to a random high port to dodge opportunistic scanners.
- **Allowlist your OIDs.** Expose only what ostr.io charts — nothing about processes or software it doesn't need.
- **Restrict the firewall** to ostr.io's checks rather than opening the port to the whole world.
- **Consider SNMPv3** where you need authentication and encryption on the wire.

Deeper hardening lives in the [security section](/security/index.md) and [secure community string](/setup/secure-community-string.md).

## Next: connect external monitoring

The reason to add an SNMP endpoint in ostr.io at all comes down to independence. A monitor running on the server can't warn you when the server is the thing that failed — a crash takes the alerter down with it. An external checker has no such blind spot: it keeps polling from outside and turns silence into a page. That's [double durability](/monitoring/double-durability.md) — better to get a notification from a second, independent source than none at all. With the dual-endpoint tip layered on top, you get both fast incident detection and a clean long-term resource trend from the same server.

Monitor add snmp endpoint ostr.io from outside your network with [ostr.io Monitoring](https://ostr.io/service/monitoring) — real-time email and SMS alerts for downtime, slow responses, and resource spikes, with no agent to install on the monitoring side.

![Diagram of ostr.io polling a server's SNMP agent from outside the network and sending email and SMS alerts](https://snmp-monitoring.com/img/setup/ostrio-external-snmp-alerts.webp)

## FAQ

**Which SNMP version do I need to add an endpoint in ostr.io?**
SNMPv2c. ostr.io's SNMP health monitoring uses v2c with a community string as the shared secret, so make sure your agent answers v2c before you start the flow.

**Why does my new endpoint show no data?**
Almost always a community-string mismatch or a blocked UDP port. Confirm the community you typed at step 8 matches `snmpd.conf` exactly, and verify the port is reachable from outside with an external `snmpwalk`. A local query that works but an external one that times out points squarely at the firewall.

**What is the dual-endpoint tip and why bother?**
Add the same server twice — one endpoint at high frequency (under five minutes) to catch spikes and outages fast, one at low frequency (one to four times a day) for a coarse long-term view. Together they give a clearer picture of resource usage than a single check.

**Do I need to install anything on the server for ostr.io?**
Only the standard SNMP agent, which most servers can run natively. ostr.io itself is agentless from the monitoring side — it polls your existing agent from outside, so there's nothing extra to deploy for the checks.

**Can ostr.io alert me, not just chart the values?**
Yes. Each SNMP metric gets a chart you can attach alert triggers to, and ostr.io sends real-time email and SMS notifications when a value crosses your limit or the host stops responding.

## Conclusion

To add an SNMP endpoint in ostr.io: sign in, open Monitoring, click Add Endpoint, select the server, set Protocol to SNMP, choose a check frequency, enter the port and community, and click Add — nine clicks against an agent that already answers v2c. Verify with `snmpget` locally and from outside, keep the community strong and the OID view tight, then use the dual-endpoint trick to get both fast alerting and a clean long-term trend. From there, an independent watcher catches the outages your own server can't report.