Features
What does inping do?
inping monitors your websites and the servers behind them: it notices when a website cannot be reached, when a page changes, when a package or runtime has a known vulnerability and when a server or Docker service runs out of resources. It then informs the right people by email or webhook.
Uptime
How does inping measure availability?
Runners request every URL of a project at the interval you choose, from several locations. A result is “up” when the expected status code comes back within the timeout.
- Interval: from 60 seconds on the free plan, from 30 seconds on the paid plans, up to one day.
- Request: HTTP(S) with GET or HEAD, expected status code and timeout per URL (up to 60 seconds).
- Per result: status code, response time, type of error (DNS, TLS, timeout, connection, wrong status) and the runner that measured.
- URLs behind a login: with Basic Auth or custom headers; the secrets stay encrypted and are shown to no one.
- Retention: raw data 7 days, daily values 365 days, 90 days of uptime per URL at a glance.
Why does an outage count only once?
The platform evaluates the latest result of each runner. If the majority reports an outage, an incident opens, and it closes only when the majority can reach the URL again. Daily uptime comes from the incidents, not from individual measurements, so one unreliable runner cannot lower it alone. To measure from inside your network, use your own runner.
Example data, modelled on the view in the app.
Change detection
How does inping detect changes to pages?
The runner fetches a page, reduces it to its text and compares that with the last version. A change triggers an event with the line diff.
- Delivery time: 2 to 3 working days
+ Delivery time: 5 to 7 working days
+ New: we now also ship to Switzerland
Example data, modelled on the view in the app.
- Scope: a CSS selector picks the part that matters, or the whole page. That keeps a changing sidebar out of it.
- Comparison: scripts, styles and markup are dropped, whitespace is reduced to one line per block, and the text is hashed. A new hash is a change.
- Storage: the platform stores the text, never the HTML, and keeps 20 versions per page.
- Interval: from 5 minutes to one week.
- Volume: 25 pages per project on the free plan, more on the paid plans.
How does inping find new pages?
A project can have its sitemap evaluated, by default the /sitemap.xml of the monitored URLs or
an address you give. The runner checks it every 6 hours, and inping reports each page that has been added.
Sitemaps of other websites are not taken over.
Vulnerabilities and end of life
Which packages and runtimes does inping check?
The agent reads the installed runtimes, the lock files of your projects and all packages of the host. The platform compares them daily with OSV and endoflife.date and reports new findings once, with severity, until an update resolves them.
| Language | Package manager | Read from |
|---|---|---|
| PHP | Composer | composer.lock |
| JavaScript | npm, pnpm, yarn | package-lock.json, pnpm-lock.yaml, yarn.lock |
| Rust | Cargo | Cargo.lock |
| Python | uv, Poetry, Pipenv, pip | uv.lock, poetry.lock, Pipfile.lock, requirements.txt |
| Go | Go modules | go.mod |
| Ruby | RubyGems | Gemfile.lock |
| Java | Gradle, Maven | gradle.lockfile, pom.xml |
| .NET | NuGet | packages.lock.json |
Runtimes: PHP, Node.js, Rust, Python, Go, Ruby, Java and .NET; reported as out of support through endoflife.date.
Host packages: dpkg, RPM and apk are compared with the advisories of the distribution, such as Debian 11 to 13, Ubuntu 20.04, 22.04 and 24.04 LTS, Alpine from 3.18, Rocky Linux and AlmaLinux. Homebrew and pacman appear only as an inventory, as do Fedora packages: inping checks no advisories for them.
Every finding links to a public page under security advisories with severity, affected versions, fixes and source. With no account, the one-line scan checks a project directory, also in a CI job.
Vulnerabilities in shop.example.com
Example entries, not real advisories.
Servers
What does the agent measure on a server?
The agent runs on the host, only reads, and writes solely to its own state directory. It sends metrics from every 10 seconds to once an hour, every 60 seconds by default, and if the platform cannot be reached it buffers for 24 hours by default, configurable up to 168.
Example data, modelled on the view in the app.
| Metric | How it is measured |
|---|---|
| CPU | Usage since the last measurement as a percentage of all cores, each core separately, load 1/5/15 (not on Windows) |
| Memory, swap | Bytes used and total, used without the file cache |
| Disks | Bytes per file system with data, each device once, 32 at most; no kernel or memory file systems, no container layers |
| Network | Received and sent in bytes per second per physical interface |
| Accounts | For each account on the host: CPU share, memory and number of processes, 64 accounts at most (Linux, Windows with -AccountMetrics) |
| Platform | System and version, kernel, architecture, CPU cores, hostname, uptime, agent version |
Scheduled jobs: daily as a list, never changed: crontabs, systemd timers, launchd and Windows Task Scheduler, each with schedule, command and user.
Retention: raw values 7 days, hourly mean, minimum and maximum values 365 days.
The agent runs on Linux, macOS, FreeBSD and Windows (amd64 and arm64) and as a Docker image. The commands for each system are under install the agent, the details in the articles Monitor a Linux server and Monitor a Windows server.
Docker
How does inping monitor Docker services?
As a Docker image, the agent moves into the Compose file of your project and reports each service separately. Services carry their names from Compose, one-off containers stay out, 64 at most per agent.
| Per service | How it is measured |
|---|---|
| CPU | Share of the CPU of the whole host, so that the services add up against the host |
| Memory | Bytes without the file cache and the limit of the container, otherwise the host memory |
| Network | Bytes per second received and sent |
| Disk I/O | Bytes per second read and written |
| State | 1 while Docker reports the container as running, otherwise 0, also in a restart loop |
The figures come from the Docker Engine API through a socket proxy that allows only read access under /containers. So the agent cannot change anything. The proxy protects the host from the
agent, not the contents of the containers: with read access it also reaches inspect output and logs of
the other containers.
In the container, host packages, scheduled jobs and runtime versions are missing. The packages of the project come from the lock files of the mounted directory. There is a guide in the article Monitor Docker containers.
Alerts and notifications
When and how does inping get in touch?
Rules per server follow one simple sentence: when a metric is above, below or equal to a value, for a number of minutes. An alert opens once and closes once.
Notifications
Example data, modelled on the view in the app.
Four default rules for every new server
- CPU above 90% for 5 minutes
- Memory above 90% for 5 minutes
- Any disk above 90%
- Any service that is not running
Rules apply to one mount or service or to all of them, can be switched off individually, up to 50 per agent. With 0 minutes they react on the next report. An agent that stops reporting is an alert of its own, after a configurable number of missed reports.
Which events trigger a notification?
- URL unreachable and reachable again
- Page changed or newly found
- Vulnerability found
- Threshold exceeded and back below it
- Agent offline and back online
- Service down and back up
- New or returning error, matching log line
Where do notifications go?
Rules per project send to the team, to up to ten external addresses and to the customer contacts of the project. External addresses receive nothing until they have confirmed by double opt-in. Webhooks are signed with HMAC-SHA256, carry a constant delivery ID for deduplication and are tried up to 6 times (from 10 seconds to 2 hours).
Logs, errors and traces
How do logs and errors reach inping?
A project accepts what the official Sentry SDKs send: install the SDK, enter the DSN of the project, and nothing else changes. inping is compatible with these SDKs but has nothing to do with the company Sentry.
| What arrives | What it becomes |
|---|---|
| Log lines | filter, search, jump to the trace |
| Errors | grouped into issues; a resolved issue that comes back counts as a regression |
| Transactions and spans | traces and the slowest endpoints |
| Session replays | mask all text and input by default and block media |
| Check-ins | cron jobs |
| Sessions | health per release |
| Feedback | messages from users |
Server logs: log sources can be added in the settings of the agent: systemd journal, file, Docker or Windows event log. With no source the agent sends no logs. On the host it removes whatever looks like a secret, and it sends every 30 seconds.
OpenTelemetry: POST /v1/logs accepts OTLP over HTTP as JSON, for example from
Fluent Bit, Vector or the OpenTelemetry Collector.
Limits: on the free plan 50 MB per day across all projects of a team and 7 days of retention; the other plans are on the pricing page. Above that, inping answers the SDKs with 429 until midnight (UTC). Logs and replays are for editors and admins, not for viewers.
Status pages
What does a public status page show?
Each project can publish a page with no login at inping.io/status/<name>: the public URLs with names, their state, 90 days of uptime and open incidents. Never the URLs themselves, servers or people.
Example data, modelled on the view in the app.
- Your own domain: by CNAME, checked by inping, certificate automatic on the first request, alongside the inping address.
- Your own look: logo, accent colour, title, introduction, support link and footer.
- For people and monitors: the page is generated as one document on the server, readable by curl and with no JavaScript.
- Live: through WebSockets it updates when a URL goes down or comes back.
- Search engines: they are asked to stay away as long as the project does not allow indexing.
The page shows what was measured. The setup is under publish a status page.
API and MCP
How do you connect inping to your own tools?
A REST API with personal access tokens and OpenAPI documentation for scripts, plus an MCP server for AI assistants. Both use the same tokens and permissions.
curl -H "Authorization: Bearer <token>" https://www.inping.io/api/v1/tenantsTokens carry the abilities projects:read and projects:write. The API is
documented at /api/docs; the MCP server is at https://www.inping.io/mcp. It offers five tools:
| Tool | What it does |
|---|---|
list-projects | projects, teams, tags and a short summary of their state |
get-project-status | URLs, open incidents, changed pages, open vulnerabilities, agents |
create-project | creates a project, with URLs if you wish (needs projects:write) |
list-issues | grouped errors of a project, individually with stack trace |
search-logs | the latest log lines, filtered by severity, service, text or trace |
The dashboard also updates through WebSockets and falls back to regular polling with no connection.
Security
How does inping protect accounts and data?
Sign-in with two-factor authentication or a passkey, roles per team and project, notices about new devices. A token can never do more than its user.
- Sign-in: two-factor authentication (TOTP) and passkeys; email notices about new devices.
- Roles: admins manage the team, editors the projects assigned to them, viewers see only those projects and neither logs nor notification rules.
- Super admins: their rights apply only with confirmed TOTP.
- Secrets: credentials for protected URLs are stored encrypted and are not displayed.
- Webhooks: follow no redirects and reach no private addresses.
The platform runs on servers in the EU, and the operator is medienakzent in Konstanz, Germany. A data processing agreement under Art. 28 GDPR is offered on the page data processing. What that means for your own obligations is described in GDPR server monitoring; you remain responsible for your own processing.
The interface and emails are available in German and English, emails in the language of the recipient.
Frequently asked questions
Questions about the features
What does inping monitor?
The availability of URLs, text changes and new pages of websites, known vulnerabilities in packages and runtimes, servers with CPU, memory, disks, accounts and Docker services, and the logs and errors of applications.
Does inping also check by ping or individual ports?
No. The uptime check is an HTTP(S) request with GET or HEAD and the expected status code. ICMP ping, port checks and SNMP are not part of the product.
How does inping prevent duplicate alerts from several locations?
The platform evaluates the latest result of each runner: if the majority reports an outage, exactly one incident opens, and it closes when the majority can reach the URL again. On a tie the previous state stays. Daily uptime is calculated from the incidents, not from individual measurements.
Where does the vulnerability data come from?
From the OSV database (OSV.dev) and, for runtimes without support, from endoflife.date. The comparison runs daily on the platform. The entries inping checks against are public at /advisories.
Is inping related to the company Sentry?
No. inping accepts what the official Sentry SDKs send, so it is compatible with them. It is not a Sentry product and is not affiliated with the company.
What is included in the free plan?
1 project, 10 URLs and 25 pages per project, 2 agents and 1 own runner. URLs can be checked every 60 seconds there. All plans are on the pricing page.