Monitor and maintain a website with Sensors and Routines

A website returning errors is a useful thing for an agent to investigate. But Agent Bridge cannot monitor an arbitrary website merely because you connected a Telegram bot. First you need a check that reports a real observation. Then you can authorise when an agent should examine it and what the agent may do.

Farstax manages the workspace; Agent Bridge supplies Sensors and Routines inside its resident runtime. The workspace agent—not Farstax Platform—owns the application, its logs and any repair.

1. Inspect what is already available

In your unified Telegram bot, send /sensors. The two built-in choices are Agent Bridge health (agent-bridge), which checks runtime state such as database access and provider health, and Server health (server), which checks host signals such as memory and load.

Choose one, or Run all sensors, and read the timestamped result. These are not checks of your website's HTTP endpoint. A green host report does not demonstrate that your application is serving customers successfully.

If you only need scheduled review of existing Agent Bridge or host health, you can use these checks without installing a website-monitoring integration. For actual website monitoring, continue to the next step.

2. Add a website signal only if you have a supported check

Website health requires an external Sensor that an operator has installed and configured in the Agent Bridge runtime. The OSS external-Sensors reference shows Content Crawler as an optional example, not an included service or a preconfigured website probe. A Content Crawler health check measures the crawler's reported health; it does not automatically measure your website's HTTP availability. For website uptime, the operator needs a separate checker that actually tests the intended endpoint.

The operator supplies a static JSON file selected by AGENT_BRIDGE_SENSOR_CONFIG. Each entry names a unique Sensor ID and label, an absolute executable path, structured arguments and an optional timeout. The OSS README's Content Crawler example shows the exact JSON shape and illustrative executable paths. Copy it only if that software is installed and the paths are valid for your host.

The executable must print one bounded JSON report containing status (green, amber or red) and a checks array, with each check's name, status and message. The runtime launches the configured executable without a shell, bounds output and execution time, and presents the report through the same /sensors menu.

This is an operator configuration, not a self-service “enable website monitoring” button in the current Farstax customer dashboard. On a managed workspace, establish the supported operator path before promising an external integration. Do not edit protected appliance configuration casually or paste credentials into chat. The Sensor convention is observation-only, but executing an arbitrary configured program is not itself an operating-system read-only sandbox: the operator must choose and audit a trustworthy check.

Once the integration is installed and the Agent Bridge runtime has loaded its configuration, run /sensors again. Verify that the new check appears, returns a plausible report and measures the website condition you intend to monitor. A working crawler-health report alone is not proof that your site is up. If a website-specific check is unavailable, stop there; there is no website signal for a Routine to inspect yet.

3. Agree a scheduled Routine with the agent

A Sensor never launches an investigation or automatically fixes anything. The scheduled-routines Skill uses a separate, explicitly authorised instruction in the conversation that will own it.

For example, only after an operator has installed and verified a genuine HTTP website-health Sensor (called site-http here as an illustration), ask:

I'd like a weekday health review at 09:00 Europe/London. Use the configured site-http Sensor. If it reports trouble, check the current source and investigate a likely cause. Report evidence and a proposed action. Do not deploy, merge or change credentials.

The agent should show you the exact proposed instruction, schedule, time zone and whether it is an ordinary companion Run or an autonomous Episode, then obtain your explicit agreement *before* it creates anything. The routine is scoped to the authenticated conversation and owner. Use the existing conversation-scoped routine helper; do not infer that an ordinary message has silently scheduled a job.

After creation, ask the agent to list and read back the Routine from that same conversation. It can request a one-off run with the supported helper to check the path without changing the schedule. If the helper or ownership context is missing, the agent should say so rather than constructing its own cron job. Provider-locked conversations cannot silently fall back to another provider; the unified conversation can use a configured, safe fallback where available.

Routines run at scheduled occurrences, not immediately when an external Sensor turns red. They grant standing authority to submit the agreed instruction, not new GitHub, host, deployment or spending privileges.

4. Investigate, review and verify

At the scheduled time, the ordinary agent Run reads the configured observation and checks whether it still represents a live problem. It can inspect relevant repository state or logs using available tools and permissions. A failing Sensor is evidence, not authority to mutate production.

For an identified code defect, use systematic debugging: reproduce, establish the cause, create a focused regression and prepare a reviewable PR if authorised. The engineering workflow guide covers independent review, exact-head CI and a merge-ready handover. A passing test, a merged PR and a healthy deployed service are different claims.

After a separately authorised deployment, verify the actual endpoint and rerun the original check. If the evidence is stale, the configuration is missing or the live condition cannot be proved, the agent should report that limit rather than announcing a repair.

What Farstax does—and does not—manage

Farstax Platform provisions and operates the workspace and its infrastructure. The resident workspace agent owns application services, processes, deployments, database changes and workload health. Stacks are researched starting briefs, not installed monitoring services; Workspace Secrets is the place for customer-owned secret values, not Telegram messages.

Start with one verified signal and one authorised Routine. Once the result is useful, you can decide whether a more extensive monitoring setup is warranted.