Monitors

Watch every website and domain across your entire fleet from one place

Monitors vs. Service Checks — what's the difference?

Astra has two ways to check whether something is reachable. It helps to understand which one to use before you get started.

Monitors

You set up a monitor once and every agent in your fleet runs it automatically. Think of it as a shared watch list — one entry, checked from every location.

Example: "Check that our company website is up and shows the word 'Welcome' — from every office, on every agent."

Service Checks

A service check is set up per agent for something that only that machine needs to reach. Other agents won't run it because it wouldn't make sense for them to.

Example: "Check that the RDP server on the 10.0.0.x network is reachable — but only from the agent at the New York office."

ℹ️

Quick rule of thumb: If you want all your agents to check something, use a Monitor. If only one specific agent should check it (because it's a local resource, an internal server, etc.), use a Service Check via that agent's settings.

DNS Monitors

A DNS Monitor watches whether a domain name resolves to the right address. Every agent performs this check and reports back, so you can see if the issue is network-wide or limited to specific locations.

This is especially useful for detecting DNS hijacking — when an ISP or a network device silently redirects your DNS lookups to a different address than expected.

What you can check

  • Whether a domain resolves at all
  • Whether it resolves to the expected IP address — any mismatch is flagged as a potential hijack
  • How long the resolution takes from each location
  • Which DNS servers are used (Google, Cloudflare, the agent's local resolver, or your own)

Setting one up

  1. Go to Dashboard → Monitors and open the DNS tab
  2. Click New DNS Monitor
  3. Give it a name (e.g. Company domain check)
  4. Enter the domain to watch (e.g. company.com)
  5. Optionally enter the IP address you expect — leave blank if you just want to track resolution time without hijack detection
  6. Choose how often to check (every 60 seconds is a good starting point)
  7. Click Create
ℹ️

Once created, every active agent in your organisation will begin running this check on its next cycle. No further setup is needed on each machine.

Reading the results

Click any DNS monitor in the list to open its results panel. You'll see a live feed of checks from all agents — the resolver used, the IP returned, the response time, and whether a hijack was detected. A green tick means everything looks correct; a red cross means the check failed or the IP didn't match.

HTTP Monitors

An HTTP Monitor visits a URL and checks that it responds correctly. Every agent does this independently, so you can immediately see whether a problem is affecting everyone or just one location.

Unlike a simple ping, an HTTP Monitor can verify that a page is not just reachable but is actually returning the right content — useful for catching broken deployments, maintenance pages, or login redirects where the server is technically "up" but the service isn't working.

What you can check

  • Whether the URL responds at all and within a timeout you set
  • Whether it returns the expected status code (usually 200)
  • Whether the page contains a specific keyword or phrase you choose (e.g. "Welcome", "healthy", or anything else that should be in the response)
  • How fast it responds from each location

Setting one up

  1. Go to Dashboard → Monitors and open the HTTP tab
  2. Click New HTTP Monitor
  3. Give it a name (e.g. Customer portal health)
  4. Enter the full URL to check (e.g. https://app.company.com/health)
  5. Set the expected status code — 200 is correct for most pages
  6. Optionally enter a keyword that must appear in the page (leave blank to skip content checking)
  7. Set how often to check and a timeout (how long to wait for a response before marking it as failed)
  8. Click Create

Reading the results

Click any HTTP monitor to see its results. Each row shows which agent ran the check, the status code returned, the response time, and whether your keyword was found. If an agent at a specific location is failing while others pass, the problem is likely local to that site's network rather than the server itself.

Editing and managing monitors

To change a monitor's settings — its URL, domain, interval, keyword, or anything else — click the pencil icon next to it in the list. This opens the same form used to create it, pre-filled with the current values. Save your changes and every agent will pick them up on their next check.

Use the toggle switch on each row to pause a monitor without deleting it. This is handy during planned maintenance when you know checks will fail. The bin icon in the results panel permanently removes the monitor and its history.

When should I use Service Checks instead?

Use Service Checks (configured per-agent in Agent Settings) when:

  • The target is only reachable from one specific site — an internal server, a local printer, an on-premise file share
  • You want to test protocols that aren't HTTP or DNS — such as RDP, SSH, SMTP, or VoIP
  • Only one agent should run the check; running it from other locations would give false failures
ℹ️

Service Check results appear on each agent's detail page under the Services tab, not in the Monitors section.

Next steps