Documentation

Install the agent

From the dashboard, choose Add service and name the VM. Foreseer hands you a discovery one-liner scoped to that host. Run it on the box — as a user that can reach your services on localhost — and it probes the default ports for Elasticsearch (9200), Redis (6379), Logstash (9600), and always captures disk and system. It then reports what it found so you can choose what to monitor.

curl -sfL "https://app.foreseer.app/api/v1/install/discover.sh?host=<host-id>&key=<api-key>" | bash

Discovery only reads service banners and host metadata — it does not change anything on your machine. The agent itself (Augur) is installed in the next step, once you confirm which services to watch.

Add your first service

After discovery, the dashboard lists every service the agent found. Select the ones to monitor and enter the connection details — a URL or host/port — and mark which need a password, for Elasticsearch, PostgreSQL, MySQL, Redis, Logstash, Nginx, Apache, Docker, JVM (via Jolokia) or PHP-FPM. Foreseer then gives you one command: curl -sfL ".../install/agent.sh?..." | sudo bash — it installs Augur and writes a single config under /etc/foreseer/foreseer.conf (and the matching telegraf drop-in). For services that need auth, you replace the REPLACE_ME placeholders in that file with your real passwords and re-run the command — the passwords stay on your VM and are carried forward across every future update. Disk and system are always included and need no credentials.

Custom services & processes

Running something Foreseer doesn't have a dedicated analyzer for — your own app, a worker, a daemon, a queue consumer? Use the process monitor. In the Add-service wizard pick Process, then list one pattern per line. Each pattern is matched against running processes (by name or as a regex over the command line) and becomes its own monitor — no credentials needed.

node
my-api
gunicorn.*master
celery.*worker

For each match you get liveness (process missing → 0 instances), restart and restart-loop detection (PID changes; ≥3 restarts in 15 min), and RSS / CPU / file-descriptor pressure against the process's limits — plus an RSS-regression memory-exhaustion forecast. Tip: prefer specific patterns (e.g. gunicorn.*master) so a monitor doesn't accidentally match unrelated processes; each pattern counts as one service against your plan.

Keep the agent current

You install once. After that, the same agent handles changes — no teardown, no re-onboarding:

• Found a new service? Re-run the discovery one-liner from the VM page. Anything new on the host (a Redis you just stood up, a second Elasticsearch node) shows up as discovered, ready to add — you don't re-onboard the VM.
• Rotated a credential? Update it in the service settings and copy the single-service update command. It rewrites only that one config drop-in and restarts the agent.
• Upgrading the agent? Run the update command from the VM page. It refreshes Augur and the base config while leaving your per-service credentials in place.

VMs, services & clusters

A VM is a host running one agent. A service is a single monitored target on that VM — a Redis instance, a Logstash node, the disk and system, or a single Elasticsearch node. A cluster is monitored from one agent: point Foreseer at the node list and you get cluster-level health plus per-node drill-down. Because each node is tracked independently, a cluster counts one service per node — an 8-node cluster is 8 services — even though there’s only one agent to install.

How insights work

Analyzers run continuously over your telemetry, fitting trends and correlating signals per service — heap against GC time, Redis memory against its eviction policy, queue depth against output throughput, disk usage against its fill rate. When a forecast crosses a meaningful line, an LLM composes a single insight that states the symptom, the likely cause, the blast radius, and the exact command to fix it — so the on-call engineer reads one paragraph instead of correlating six graphs at 2am.

Severities & lifecycle

Every insight carries a severity and moves through a simple lifecycle:

• Critical — action needed soon; a failure is forecast or already unfolding.
• Warning — a trend worth watching before it becomes critical.
• Acknowledge — mute the noise while you work; it stays in the list, dimmed.
• Auto-resolve — when the underlying condition clears, Foreseer closes the insight for you. No stale alerts to sweep up.

Roles & permissions

Three roles, enforced on every read and write:

• Admin — creates VMs, manages billing, the team, and connectors org-wide.
• Project Manager — manages the services and alerts for the VMs they're granted; sees only those projects' insights and metrics.
• Viewer — read-only across the org.

Inviting teammates

Admins invite teammates by email from Settings → Team and assign a role at invite time. Each plan includes a number of seats; the invite form shows your remaining seats and blocks over-allocation until you upgrade. Roles can be changed later without re-inviting.

Per-VM access

Project managers only see the VMs they're granted. Grant or revoke access per VM from team settings — useful for agencies and platform teams where each manager owns a distinct slice of the fleet. The scope is enforced everywhere: dashboards, insight lists, and metric queries all filter to the manager's hosts. Admins and viewers span the whole org.

Alerts & connectors

A connector is a reusable alert destination — a Slack webhook or an email recipient list — created once under Settings → Connectors. A fresh connector is silent until you attach it to a service from that service's page, so nothing fires by accident. Attach one connector to many services, or many connectors to one; alerts route only along those links.

Email works on every plan, including the free trial. Slack requires the Starter plan or higher — the app shows an upgrade prompt rather than silently dropping the alert. Generic webhooks are on the roadmap.

Security & data

Service credentials never reach us — they're written into the agent config on your own host and stay there. We receive numeric metrics and lightweight metadata (versions, cluster names, host and cloud labels) over TLS, never log contents or key values. Per-VM tokens are independently revocable, and the time-series layer is VictoriaMetrics-compatible so it can run inside your own environment on Enterprise.