Service health, uptime, and incidents

Always watching. Never blinking.

Vigil polls the health endpoints and websites you give it, records every answer, and opens an incident the moment a check fails. A scanner crawls any site for broken links.

Illustration: a lone stone lighthouse on a dark coast with a soft violet beam sweeping across calm water.
Features

Know before your users do.

Vigil checks, records, and tells you. These are the things it does today.

Endpoints, latency, and uptime

01

Checks on a schedule

Each site has its own interval (10 seconds to an hour), timeout, expected status code, and optional request headers. Checks run inside the Vigil service itself, so there is no separate worker to keep alive.

02

A health report, when there is one

If the endpoint answers with JSON that has a status of healthy, degraded, or unhealthy, Vigil uses it. Otherwise a response with the expected status counts as healthy, and anything else as down.

03

Five results, three colors

Every check is stored as healthy, degraded, unhealthy, timeout, or error. The dashboard shows them as healthy, degraded, and down.

04

Uptime over four windows

24 hours comes from the raw checks. 7, 30, and 90 days come from daily summaries that Vigil builds itself. A degraded check counts as up.

05

Latency you can read

Every check keeps its response time. A site's panel charts it over 1 hour, 6 hours, 24 hours, 7 days, or 30 days, with a 95th-percentile line.

06

Three kinds of site

API services, front-end apps, and websites each get their own group on the dashboard. Websites and front ends can be scanned; APIs cannot.

From the first failed check to the all-clear

07

Incidents open themselves

The first check that comes back unhealthy, timed out, or errored opens an incident; the first one that does not closes it and records how long it lasted. A degraded site never opens one.

08

A red banner and an alarm

While any site is down, a banner counts them and an alarm sounds, repeating every 30 seconds. A chime plays when everything recovers. The header mutes the alarm, and the choice is saved.

09

Updates and a public title

An incident takes severity (minor, major, critical, or maintenance), a public title, and posted updates marked investigating, identified, monitoring, or resolved. Posting resolved closes it.

10

Chirp alerts

Point one setting at a Chirp channel webhook and Vigil posts when a site goes down or recovers, when one flaps (three incidents in 30 minutes), and when one has been degraded for five checks in a row.

11

Live updates

Check results and incident changes are pushed to every open dashboard over a WebSocket, which reconnects on its own. The dashboard also paints at once from the browser's cache when you reload.

12

A public status page feed

A site shows on the public status API only when an operator turns that on for it. The feed carries a name, a description, status, and uptime, and never a URL, header, or error message.

Crawl a whole site, not just its front door

13

A real crawl

The scanner starts at the site's address, follows same-site links breadth-first, obeys robots.txt unless told not to, and keeps to a rate you set (0.5 to 20 requests a second). Tracking parameters are stripped from URLs.

14

Broken links, inside and out

Every internal link that errors, and every external link it can check, is listed with its status code.

15

Five page checks

Missing or badly sized titles and descriptions, pages with almost no text, a footer that differs from the rest of the site, pages that duplicate each other, and broken links.

16

A sitemap

The pages the crawl found, drawn as a tree or as a graph of how they link.

17

What changed since last time

The previous scan is kept for 14 days. The Diff tab lists pages added, removed, and changed, and shows the text change for any page.

18

One scan at a time

A lock keeps a site to one running scan. A scan can be canceled, and one that runs for an hour is stopped.

Screens

See it in light and dark

Real captures of the running tool, with fictional StrataForge Robotics data. They follow your theme.

How it works

From an address to an alarm

  1. Add a site

    Give it a name, a kind, a URL, how often to check, and what a healthy answer looks like.

  2. Check

    On its schedule Vigil requests the URL and records the status, the time it took, and any health report in the body.

  3. Decide

    A down result opens an incident, sounds the alarm, and tells every open dashboard. A degraded result is recorded and shown, and nothing opens.

  4. Recover

    The first good check closes the incident, records its length, and clears the banner. Uptime updates on the next read.

Accessibility

Built so everyone can use Vigil.

Vigil is built with a skip link, landmarks, live regions for the alarm and for loading, and a visible focus ring, and it has one automated accessibility test. We read the code for the gaps below on 10/29/2026 and fixed one of them (the incident dialog was hidden from assistive technology). Nobody has used it with a screen reader, and we do not claim a WCAG conformance level.

  • Partly supported

    Keyboard operation

    A skip link jumps to the main content, focus shows a 2 pixel outline, Escape closes the add-site, scan, page-detail, site-detail, and incident dialogs, and cards are focusable buttons. List rows, incident rows, and sortable column headers can only be used with a mouse.

  • Partly supported

    Screen reader landmarks and labels

    Pages use a main landmark, a labeled region for each group of sites, and live regions (role alert on the alarm banner and on errors, role status on loading and scan progress). The incident dialog used to sit inside an element hidden from assistive technology; that is fixed and tested. The site panel is not announced as a dialog, the latency chart has no text alternative, and the sparkline is decorative.

  • Not yet tested

    Contrast in light and dark

    Contrast was not measured on the screens with data in either theme.

  • Partly supported

    Reduced motion

    The design system's stylesheet shortens CSS animation and transition durations when the reduced-motion setting is on. Motion done in JavaScript (cards and panels sliding in) does not follow that setting yet.

  • Not yet tested

    Text resize and zoom

    Zoom and larger default text sizes were not tested.

  • Not yet tested

    Mobile and touch

    The layouts have mobile rules, but a phone-sized pass has not been done on the screens with data. Many controls are smaller than 44 pixels (the header icon buttons are about 28).

Tech specs

Under the hood

Vigil technical specification
Backend
  • Python and FastAPI
  • SQLAlchemy 2 (async) on PostgreSQL, with Alembic migrations
  • APScheduler for checks, run inside the service
  • httpx for requests; Valkey for scan results
Frontend
  • React 19 and TypeScript
  • Tailwind with the Renkara design system
  • Recharts for latency, React Flow and a tree view for sitemaps
  • Light and dark themes that follow the system
Monitoring
  • HTTP status and response time
  • The endpoint's own health report, when it sends one
  • Per-site interval, timeout, expected status, and headers
  • Daily uptime summaries; raw checks kept 30 days by default
Scanner
  • Breadth-first, same-site crawl with robots.txt support
  • Five page checks and external link checks
  • Sitemap tree and graph, and a diff between scans
  • Results kept in Valkey; the last scan for 14 days
Access
  • A REST API and a WebSocket for the app
  • A read-only public status API, opt-in per site
  • 36 MCP tools for agents
  • Security headers on every response
Stands in for

UptimeRobot, Pingdom

Works with

Part of the Renkara fleet

MCP tools

Built for agents as well as people

Agents can add and change sites, read checks, uptime, and incidents, start and read scans, and read fleet diagnostics. Two of the tools are known to answer badly today: get_dashboard and get_fleet_health_summary.

Sites

  • list_sites
  • get_site
  • create_site
  • update_site
  • delete_site
  • get_site_checks
  • get_site_latency
  • get_site_incidents
  • get_site_uptime
  • trigger_check

Incidents

  • list_incidents
  • get_incident
  • update_incident

Settings

  • get_dashboard
  • get_settings
  • update_settings

Scans

  • start_site_scan
  • get_scan_status
  • cancel_scan
  • get_sitemap
  • list_broken_links
  • list_page_issues
  • get_scan_diff
  • get_page_details
  • list_scan_pages
  • get_page_text_diff

Fleet diagnostics

  • check_service_health
  • get_diagnostics
  • get_tool_diagnostics
  • get_fleet_health_summary
  • list_fleet_tools
  • add_fleet_tool
  • remove_fleet_tool
  • refresh_fleet_tools
  • get_fleet_diagnostics_summary
  • get_fleet_tool_diagnostics_report
FAQ

Questions people ask

Does Vigil do everything UptimeRobot or Pingdom does?

No. It checks status codes and, when the endpoint sends one, a health report, from one place. It does not read certificates, assert on page content, probe from several regions, or send email or SMS.

What makes a site degraded?

The endpoint says so. A health report with a degraded status is shown as degraded. Vigil does not decide that from how slow the answer was.

Does a degraded site raise an alarm?

It is shown in amber and counted, but it opens no incident and sounds no alarm. After five degraded checks in a row Vigil can post one Chirp alert.

Does Vigil have incident acknowledgment?

There is no acknowledge step. You can post updates and change the severity and public title, and posting a resolved update closes the incident.

Is Vigil for sale?

Vigil is the Renkara fleet's own monitor. For anything else, write to contact@renkara.com.

Contact

Questions about this tool?

Write to Renkara Media Group and a person will answer.