FlareWarden

Use this when the user has confirmed a plan_content_check plan. Returns the content check created, with its id. Spends one monitor. Safe to repeat: the same plan id returns the first result. Not for changing an existing check: use update_monitor.

Use this when the user has confirmed a plan_cron_monitor plan. Returns the job's ping URL and ready-to-paste code for crontab, start/complete/fail reporting, GitHub Actions, a Kubernetes CronJob and a systemd timer. Spends one monitor. Safe to repeat: the same plan id returns the first result and the same URL. Not for changing an existing job's schedule: use update_monitor.

Use this when the user has confirmed a plan_dependency plan for a site already monitored. Returns the dependency created, with its id and how it is watched. Spends one monitor. Safe to repeat: the same plan id returns the first result. Not for a dependency inside a plan_site plan: create_site adds those with the site.

Use this when the user has confirmed a plan_dns_watch plan. Returns the watch with the values it starts from. It costs no monitors. Safe to repeat: the same plan id returns the first result. Not for removing or changing a watch: that is done on the site's DNS page, which the result links.

Use this when the user wants another of their sites, or a group heading, shown on one of their status pages. Returns what was added: a site with the checks chosen under it, placed in a group if one is named. A site already on the page gains only the checks it did not show, and a group that exists is not added twice. Not for creating a page: use plan_status_page.

Use this when the user wants FlareWarden to send alert events to their own HTTPS endpoint (a generic, signed JSON webhook), or to connect Slack, Discord, Google Chat or Microsoft Teams. For an endpoint: creates the webhook and returns a one-time link where the user sees its signing secret (the secret never appears in the chat). For a chat destination: returns the page where the user pastes the channel's webhook URL, which works as a password and is never a tool argument. Owners and admins only. Not for the user's own alert emails: use update_my_notifications. The webhook format, events and signature are documented at https://flarewarden.com/docs/alerts/webhooks.

Use this when the user has confirmed a plan_bulk_pause plan. Returns each site's outcome: paused or resumed, already so, or refused with the website's reason (a resume that does not fit the plan's running monitors is refused, the others still go ahead). Safe to repeat: the same plan id returns the first result. Not for deciding which sites: call plan_bulk_pause first.

Use this when the user has confirmed a plan_dependency plan that changes which components of a dependency the site already watches, or how serious each is. Returns the dependency as it now watches. Spends no monitors. Safe to repeat: the same plan id returns the first result. Not for adding a dependency the site does not watch yet: add_dependency adds one.

Use this when the user calls off planned work: a scheduled or running maintenance window, or a recurring schedule as a whole. Cancels it as the dashboard's Maintenance page does; the subscribers who were told about it are emailed that it will not happen. Returns the cancelled window. A window already cancelled is left as it is. Not for an incident: use draft_incident_post with kind resolve.

Use this when the user wants a monitor-only member, such as a client, to see more of the account's sites, to view or edit a site they can see, or to stop seeing one. Returns the sites the member can see after the change. A site is added at once, with no invitation or email; removing one asks the user to type the site's name where the client can show a form, as the team page does. Owners and admins only. Not for someone not on the team (use invite_member), an account-level member (change_member_role changes their role; the website makes one monitor-only only by removing them in the dashboard and inviting them again with sites), or a member's last site, whose removal removes them from the team (done in the dashboard).

Use this when the user wants a team member to have a different role (admin, editor or viewer) or to cover different monitors. Returns the member's old and new role; FlareWarden emails the member about the change. Owners and admins only: nobody changes their own role or the owner's, and only the owner changes an admin's. Not for inviting someone new (use invite_member) or removing a member (done in the dashboard).

Use this when the user asks whether a third-party service such as Stripe, AWS, GitHub, Slack, OpenAI or Cloudflare is down, slow or having an outage, or why something that depends on one is failing. Returns what FlareWarden's public status page for the service shows: the vendor's own status page and FlareWarden's checks from several regions side by side, the verdict (the worse of the two), open and recent incidents, response times and 7, 30 and 90-day uptime. Covers hundreds of popular services, by name or domain. Not for a specific URL or the user's own website: use check_service_status_url.

Use this when the user asks whether a specific website, URL or API endpoint is down, unreachable or slow: "is my site down or is it just me?", "is api.example.com reachable from Europe?". Requests the URL once from six regions (Ashburn, San Jose, London, Frankfurt, Singapore and Sydney) and returns each region's result (up, down, blocked or inconclusive), status code and timings, with an overall verdict. A host is checked at most once every 5 minutes; a repeat returns that result and its age. Never returns page content. Not for named third-party services like Stripe or AWS: use check_service_status, which also reads the vendor's own status page. Not for a site the user monitors with FlareWarden: diagnose_site checks it from every region FlareWarden checks from, as its own monitoring.

Use this when the user has confirmed a plan_site plan and its cost. Returns what was created for each site (the site, its page checks and dependencies, with ids), anything left out because the plan filled up, and what to set up next. Spends the monitors the plan priced. Safe to repeat: the same plan id returns the first result. Not for a plan the user has not seen: show them plan_site's summary first.

Use this when the user has confirmed a plan_status_page plan, including publishing it. Returns the new page's public address and what it shows. The page is public as soon as it is created. Safe to repeat: the same plan id returns the first result and never a second page. Not for changing an existing page: use update_status_page.

Use this when one of the user's own sites is down, failing from some places, slow or alerting, and they want to know why right now, or want it checked from everywhere: "why is shop.acme.com down?", "is it failing everywhere or just in Asia?", "is our site reachable from every region?", "is it our certificate?". Requests the site once from every region FlareWarden checks from and returns each region's result, status code, DNS, connect, TLS and first-byte times, where a failure stopped, and the certificate's issuer and expiry, with a one-line finding such as "fails only from Singapore: TLS handshake timed out". At most 10 an hour for one site; a repeat within a minute returns the same result. Never returns page content. Not for past outages or why a site keeps alerting: use get_incident or review_noise. Not for a site outside the user's FlareWarden account: use check_service_status_url.

Use this when the user says an unusual response or run time was expected (a deploy, a sale, a migration). Returns the anomaly's new state. A dismissed anomaly no longer counts and is left out of future baselines; dismissed false restores it. Not for turning anomaly detection off: use set_anomaly_detection.

Use this when the user says not to suggest something again: a status page, an alert channel, inviting a teammate, cron monitoring, subdomains or anomaly detection. Returns which suggestion is off. It stays off for this member in every assistant's conversations; the dashboard's own prompts are dismissed on the dashboard. Not for declining once: leaving a suggestion unanswered is enough.

Use this when the user wants to tell customers about a problem on one of their sites: declare a new incident, post an update on one, or resolve one. Returns the exact text, every status page it will appear on, how many subscribers, members and webhooks will be notified, and any conflict (such as an incident already open on that site), with a draft id. Posts nothing. Not for reading what happened: use get_incident.

Use this when the user plans work on a site (a deploy, an upgrade, a migration) and wants it marked as maintenance, once or on a schedule, optionally telling status page subscribers. Returns the window in the user's time zone (and the next occurrences of a recurring one), the status pages it shows on and how many subscribers would be emailed, with a draft id. Schedules nothing. Not for an outage that is already happening: use draft_incident_post.

Use this when the user asks what FlareWarden can do or what it costs: "can FlareWarden watch cron jobs?", "how do you confirm an outage?", "what does a status page cost?", SSL certificate expiry, DNS changes, heartbeats, third-party dependencies, SLA and uptime reports, maintenance windows, alerts to Slack. Returns a catalogue of features (what each does, when it helps, how it works, its limits and plans) and the plans with their prices and limits. Pass a topic to get only the matching features; leave it out for all of them.

Use this when starting any conversation about the user's own FlareWarden account, or when they ask what is wrong, what needs attention, or what they could set up next. It needs that account: on a connection not yet signed in, the call starts FlareWarden sign-in. Returns who is connected (account, plan, role, permissions), how much monitor room is left, sites by status, open incidents with how they were confirmed, an attention list worst-first, and up to three suggestions. Not for someone with no FlareWarden account who wants a site monitored. Not for another company's service status: use check_service_status.

Use this when the user asks whether an outage was real, how it was confirmed, when it started and ended, what else it affected, or who was told. Returns the incident with its evidence: the regions that confirmed it and how, which region failed first and when, false alarms overturned around it, checks rolled into it, its updates, and who was notified (member emails, webhook deliveries, status page subscriber notices). Also what was happening outside the site at that time, with a one-line finding: the site's dependency checks by region, and for each third-party service it relies on, what the vendor's status page reported and what FlareWarden's own checks of that service recorded. Not for listing incidents: use list_incidents.

Use this when the user asks what a site's recent checks, response times or failures looked like, or how a cron job, content check or dependency has been running. Returns the most recent checks of the site, or of one of its content checks, dependencies or cron jobs (runs, durations, late or failed runs), newest first. Not for uptime percentages or totals over a range: use get_report.

Use this when the user asks which alert emails they get from FlareWarden, or before changing them. Returns their own switches for this account: monitor_down (a monitor goes down), monitor_recovered (a monitor comes back up), ssl_expiring (warnings before an SSL certificate expires, at the ssl_expiry_warning_days), domain_expiring (reminders before a site's domain registration expires), certificate_changed (a site's SSL/TLS certificate has been replaced), issuer_changed (a certificate for the site's domain from an issuer it does not expect appears in public Certificate Transparency logs), ssl_tls_changes (protocol version or cipher suite changes), dns_failures (one switch for DNS resolution failures, changes to a site's DNS records and alerts from the DNS records the user watches), performance_anomalies (an unusual slowdown while the monitor is still up, for monitors with anomaly detection on); the master email switch; and their SSL expiry warning days. Not for webhooks or Slack, Discord, Google Chat and Microsoft Teams alerts: use list_webhooks.

Use this when the user wants an uptime, SLA or incident report for a site, a group (an agency's client) or the whole account, for a week, month or quarter. Returns uptime over the time FlareWarden measured (unknown is shown as unknown), downtime minutes (the time that uptime counts as down), degraded minutes (affected but up, not downtime), incident count, longest incident and mean time to recover, response time p50 and p95, and certificate and domain expiry; for one site, also uptime, downtime and degraded time by day, response times over the range and each incident. Not for the latest checks: use get_monitor_history.

Use this when the user asks about one of their websites or APIs: is it up, why is it down, what is checked on it, when its certificate or domain expires. Returns status and last check; its content checks, dependencies and cron jobs (children, each with when it last and next runs, and a check's interval); SSL and domain expiry; anomaly detection; maintenance now and in the next 7 days; and open incidents; with include, its DNS records and DNS watches, the subdomains found in certificate logs, or the certificates those logs list for its domain and which issuers it expects. Not for past checks or uptime over a range: use get_monitor_history or get_report.

Use this when the user asks what one of their status pages shows, which sites and checks are on it, or why its custom domain is not working. Returns the page with its components in order (with the ids the component tools take), its public URL, its subscriber count, and its custom domain's DNS record, verification and certificate state. Not for incidents posted on it: use list_incidents.

Use this when the user asks how many monitors they have left, what their plan includes, or why they cannot add more. Returns the monitor pool (used, allowed, left; websites, child checks and anomaly detection), status pages, seats, webhooks, subscribers, history kept and the fastest check interval. Not for which sites are down: use get_account_overview or list_sites.

Use this when the user wants to give a person access to their FlareWarden account: a teammate at a role (admin, editor or viewer), or a client who should see only some sites (a monitor-only invitation with sites). Emails the person an invitation link and returns exactly who was emailed; inviting the same address again replaces its pending invitation of the same kind (a site invitation only one for exactly the same sites) and emails it again. Owners and admins only; an admin cannot invite an admin. Not for changing the role of someone already on the team: use change_member_role.

Use this when the user asks what went down, whether anything is down now, what happened last night or this month, or what maintenance is planned. Returns incidents (open or resolved, with how each was confirmed) or maintenance windows, for one site, a group or the account, newest first. Not for one incident's full evidence: use get_incident.

Use this when the user asks which websites or APIs they monitor, which are down, slow or paused, or what is in a group. Returns each site's status, last check, response time, 24-hour uptime, group, interval and SSL days left, filtered and paged. Not for one site's detail: use get_site.

Use this when the user asks about their public status pages: which they have, their addresses, how many subscribers, or whether a custom domain works. Returns each page with its public URL, custom domain state, component and subscriber counts, and the plan's page limit. Not for another company's status: use check_service_status.

Use this when the user asks who has access to the account, what roles people have, who was invited, or how many seats are left. Returns members with role, scope, the sites shared with them and when they joined and were last active (on the website or through an AI agent), pending invitations with the role or sites each gives, and seats used and allowed. Owners and admins only. Not for who was alerted about an incident: use get_incident.

Use this when the user asks whether a webhook or chat channel got a particular alert, why one is failing, or what was sent to it lately. Returns its latest deliveries, newest first: each one's event, when, whether it arrived, the HTTP status, how long it took, which attempt it was and, for a failure, what went wrong in a few words. Never the payload or what the endpoint answered. Not for the account's webhooks as a whole (use list_webhooks) or sending one again (use retry_webhook_delivery).

Use this when the user asks where FlareWarden sends alerts besides email: their webhooks and Slack, Discord, Google Chat or Microsoft Teams channels, which events and sites each covers, and whether deliveries are failing. Returns each destination with its host (never the full URL, which often carries a credential), events, sites, active or paused, and delivery health. Owners and admins only. Not for the user's own alert emails: use get_my_notifications.

Use this when the user wants to pause or resume several sites at once: a group, a list of sites, or every site, for example during a migration or a move to a new host. Returns exactly which sites would change, which are already paused or running, and which can't be changed (no permission, shared from another account, or no room on the plan to resume), with a plan id. Changes nothing. Not for one site or one of its checks (use set_monitor_paused), or for planned work with an end time on one site (draft_maintenance).

Use this when the user wants FlareWarden to watch what a page of their site says or shows: that a text or button is there, an error message is not, a price stays in a range, or the page changes. Returns the check tried against the live page right now (passes or not) and where the page holds its text, or the automatic checks that hold there when no check is named; any check of the site that already looks for the same text; its cost in monitors against the room the plan has left; and the decisions to put to the user: how serious a failure is and how often to check. Changes nothing. Not for whether the site is up: plan_site watches that.

Use this when the user wants to know if a scheduled job, backup, queue worker or other background task stops running, runs late or fails. Returns the schedule understood (with the next five runs in the user's time zone), its cost in monitors against the room the plan has left, and the decisions to put to the user: when the job runs, if the schedule given could not be read; then how late is too late (with a recommended grace period), the longest normal run and how serious a miss is. Cron expressions are read in UTC: there is no time zone setting. Changes nothing. Not for checking a website or API endpoint: use plan_site.

Use this when the user wants FlareWarden to watch a third-party service a site relies on (a cloud provider, CDN, payment, email or auth service), either while planning a new site or for a site already monitored. A service FlareWarden's catalogue does not list is watched through its status page (url), or a URL checked over plain HTTP. Returns how the service will be watched (its status page integration, or a plain HTTP check), its cost in monitors against the room the plan has left, then the decisions one step at a time: regions (recommended from the site's DNS), which components count, then, once they are chosen, how serious each one's failure is; the interval is the recommended one unless the user names another. Credentials such as an API token are entered on a secure link it returns, never in the chat. Changes nothing. Not for checking whether a service is down right now: use check_service_status.

Use this when the user wants to know if DNS records under one of their sites change or stop resolving: their MX records, _dmarc, SPF, or the CNAME a subdomain points at (such as www pointing at Vercel). Returns the name's values today for the record types asked (or all of them), and the decisions to put to the user: which record types, and whether to alert when the values change or when the name stops resolving. Watches cost no monitors; a site can have 20. Changes nothing. Not for the site's own uptime, DNS health or certificate: FlareWarden checks those already.

Use this when the user wants FlareWarden to monitor a website or API they run, or up to 50 of them at once. Returns a plan: what each site runs on (hosting, CDN, cloud regions, payments and other services, found from its DNS and page), which automatic page checks hold on it now, and the decisions to put to the user with recommendations and their cost in monitors. Changes nothing; call again with the plan id and the user's answers. Not for adding a check to a site already monitored: use plan_dependency, plan_content_check or plan_cron_monitor.

Use this when the user wants a public status page for their customers, made from one of their sites or empty. Returns a suggested address (with free alternatives when one is taken), the branding found on the site, the components the page would show grouped as the editor groups them, what the plan allows (components per page, custom domains), and the decisions for the user: the address, which of the site's services to show, and whether to publish. Changes nothing. Not for another company's status: use check_service_status.

Use this when the user has approved a draft_incident_post draft's exact text and recipients. Posts it as the dashboard's Incidents tab does: it shows on the status pages and FlareWarden emails the subscribers, members and webhooks the draft named. Returns the incident. Safe to repeat: the same draft id posts once and returns the first result. Not for changing the text: make a new draft.

Use this when the user asks what they should monitor for a website, what could take their site down, or which third-party services (hosting, CDN, DNS, payments, email, analytics) a site depends on, and when someone with no FlareWarden account asks what monitoring a site would get before signing up. Reads the site's DNS records, home page and certificate and checks it from six regions. Returns the services it recognizes with the evidence for each and their status now, the certificate's expiry, a DNS summary, whether the site is up now, the page checks that would work on it, and what FlareWarden would create and how many monitors that is, on each FlareWarden plan. Needs no sign-in and stores nothing about the user; results are cached per site for a day. Not for whether a site is up right now on its own: use check_service_status_url. Not for creating monitoring: once the user is signed in, the account tools plan and create it. What it detects is documented at https://flarewarden.com/docs/smart-setup.

Use this when the user wants a site, check or group heading taken off one of their public status pages. A site goes with its own content, dependency and cron rows, wherever they are placed. A group goes alone and its items move to the top level where it was, unless group_contents is remove, which takes everything in it off the page too. The sites and checks themselves stay monitored. Returns what was removed and the page's components after. Not for deleting a site, a check or the page itself, which is done in the dashboard.

Use this when the user wants the FlareWarden account's own name changed: the name its members see in the sidebar and account switcher, and invitations carry. Renames it as the Account page does and returns the old and new name. Owners and admins only. Not for a site's name (use update_monitor) or a status page's (use update_status_page).

Use this when the user wants a delivery a webhook or chat channel missed sent again, once the endpoint is fixed. Sends the same event again as a new attempt, as the Webhooks page's Retry does, and returns whether it arrived and the HTTP status. Owners and admins only. Not for a test event (use test_webhook).

Use this when the user asks what they are not monitoring, what could break without them knowing, whether their monitoring is complete, or what to set up next. Returns the gaps in what the user can see, worst first, each with the tool that fixes it and, where the user may turn that suggestion off, the dismiss_suggestion key: services FlareWarden found a site relying on that no dependency watches, certificates expiring within 30 days (tracked subdomains included), sites on no status page, sites whose alerts reach one person or nobody, and monitors paused for weeks. Changes nothing in the account. A site whose services FlareWarden has not looked at in the last week has its DNS records and home page read in the background, and a later call includes what that finds. Not for what is down now: use get_account_overview.

Use this when the user asks why a site keeps alerting, which monitors are noisy or flapping, whether alerts were false alarms, or how to get fewer pointless alerts: "why does FlareWarden keep emailing us about the API?", "which of our monitors are flaky?". Returns, over the last 7 and 30 days for the sites the user can see, worst first: alerts for outages the next check found over, content checks, dependencies and cron jobs that alert often, anomaly alerts, sites whose status keeps changing, and failed checks other regions overturned as false alarms (by region); each with a suggested change and the tool that makes it. Changes nothing. Not for what is down now: use get_account_overview or diagnose_site. Not for what is not monitored: use review_coverage.

Use this when the user wants to withdraw an invitation that has not been accepted yet. Returns which invitation was cancelled; the link in its email stops working and nobody is emailed. Owners and admins only. Not for removing someone who already joined: that is done in the dashboard, and the result gives the link.

Use this when the user has approved a draft_maintenance draft. Schedules it as the dashboard's Maintenance page does: it shows on the status pages, and subscribers are emailed only if the draft said so. Returns the window and its id. Safe to repeat: the same draft id schedules once. Not for changing a window already scheduled: update_maintenance moves, extends, renames or ends it.

Use this when the user asks who changed something in the account and when: who paused a site, who invited someone, what an AI agent did. Returns entries newest first with the time, the member, the action, what it changed and, for changes made through an AI agent, which one (via). Owners and admins only. Not for monitoring history or incidents: use get_monitor_history or list_incidents.

Use this when the user asks how to do something in FlareWarden, such as adding a custom domain to a status page, sending alerts to Slack, adding a cron job heartbeat, allowlisting probe IPs or inviting a teammate. Searches the documentation at flarewarden.com/docs and returns the best-matching passages with links to their pages.

Use this when the user asks whether FlareWarden can watch a third-party service their site depends on (a payment provider, cloud, CDN, email or auth service). Returns matching services with their category and status page, and FlareWarden's public status page when there is one. Not for whether a service is down now: use check_service_status.

Use this when the user wants FlareWarden to alert on unusual response times of a site, or unusual run times of a cron job, or to stop doing so or change how sensitive it is. Returns whether it is on, its sensitivity, and its recent anomalies. Turning it on costs one monitor; turning it off frees it. It learns for 3 days before reporting. Not for ordinary up or down alerts, which every monitor sends.

Use this when the user wants to stop or restart checks of a site or one of its checks, for example during planned work. Returns the new state and what it means: pausing a site stops its checks, content checks and dependencies, holds its DNS watch alerts, and resolves its open automatic incidents, but its cron jobs keep alerting until each is paused; pausing frees no room on the plan; resuming must fit the plan's active monitors. Not for scheduling maintenance windows or deleting a monitor: those are in the dashboard.

Use this when the user wants to check that a webhook or chat channel receives FlareWarden's alerts. Sends one test event to the destination now, records the delivery, and returns whether it arrived and the HTTP status. Owners and admins only. Not for the delivery history of real alerts: use list_webhook_deliveries.

Use this when the user wants FlareWarden to watch the TLS certificate of a subdomain it found under a site (from public certificate logs), or to stop. Returns the subdomain's tracking state and, when tracking starts, its certificate's issuer and expiry. A tracked subdomain gets a daily certificate check and expiry alerts, at no cost to the plan. Not for checking the subdomain itself is up: plan it as a site with plan_site.

Use this when the user wants to change planned or running maintenance: end it early or start it now, extend or move it, rename it, or pause or resume a recurring schedule. Changes it as the dashboard's Maintenance page does and returns the window as it is now. A window that asked to tell subscribers emails them as the page's would: the new time when a one-time window moves, and that it started or ended. Not for new work (use draft_maintenance), calling it off (use cancel_maintenance) or an outage (use draft_incident_post).

Use this when the user wants to change how a site or one of its checks is watched: a site's name, interval, timeout or group; a content check's text, selector, page, kind, attribute, limits, description, severity or interval; a dependency's name, description, severity or interval, and a plain HTTP dependency's URL and expected text; a cron job's schedule, grace period, longest run, description or severity. Returns the settings now in force. Only the fields given change. Not for pausing (use set_monitor_paused), deleting (the dashboard does that), or a dependency's components (plan it again with plan_dependency). Each setting is documented at https://flarewarden.com/docs/monitors.

Use this when the user wants FlareWarden to email them more or fewer kinds of alert, pause or resume all alert emails, or change when SSL expiry warnings arrive. Changes only the settings given, for the user alone, and returns all of them after the change. Not for teammates' alerts, webhooks or chat channels.

Use this when the user wants to change an existing status page's name, description or custom domain, its colours or logo, what it displays (time zone, incident history, uptime days, subscribe form), or its search title and description. Changes one section at a time (general, branding, display or seo) with the editor's own checks and returns the section as saved; setting a custom domain returns the DNS record to create. The page's address (slug) never changes. Not for the services it shows: use add_status_page_component or update_status_page_component.

Use this when the user wants a service or group on one of their status pages renamed, described differently, moved into or out of a group, or moved up or down. Returns the component as saved and the page's components in order. Not for taking one off the page: use remove_status_page_component.

Use this when the user wants a webhook or chat channel to get different alerts: rename it, change the events or sites it is sent, turn it off or on, or move a custom webhook to a new URL. Changes it as the Webhooks page's edit does and returns it as it is now; only the fields given change. Turning one on is held to the plan's active webhooks. Owners and admins only. Not for a chat channel's URL, its request headers or its signing secret, which stay on the Webhooks page, or for adding one (use add_webhook). The webhook format, events and signature are documented at https://flarewarden.com/docs/alerts/webhooks.