canonical: https://jentic.com/apis/phare.io/phare # Phare The Phare API runs uptime monitoring, incidents, and status pages for the phare.io platform. It creates HTTP, TCP, and ICMP monitors that check from up to six regions at intervals from 30 seconds to an hour, pauses and resumes them, and reports uptime statistics per monitor or across a project for a time window. Incidents carry an impact level and a timeline of updates, maintenance windows can be scheduled, cancelled, or completed, and alert rules route events to integrations such as Slack, Discord, Telegram, email, SMS, ntfy, ilert, Pushover, and outgoing webhooks. ## For AI agents Create and pause Phare uptime monitors, read uptime reports, open and update incidents, schedule maintenance windows, and manage status pages and alert rules. ## Scope Does not collect application logs, traces, or performance metrics, and does not run on-call paging schedules. Use for uptime monitors, incidents, maintenance windows, and status pages only. ## Capabilities - Create HTTP, TCP, or ICMP uptime monitors with check regions, an interval, and success assertions - Pause and resume a monitor during planned work, or delete it - Report uptime statistics for one monitor or the whole project between from and to timestamps - Open an incident with an impact such as partial_outage or major_outage and post updates through investigating to resolved - Schedule, cancel, and complete maintenance windows tied to monitors and status pages - Publish status pages with a subdomain or custom domain and read a page's current status - Route alert events to Slack, Discord, Telegram, email, SMS, or outgoing webhook integrations ## Use cases ### Incident response agent through Jentic When an alert fires, an AI agent can handle the status communication while engineers fix the problem. Through Jentic the agent searches for 'open an uptime incident', loads the Phare createUptimeIncident operation with its input schema, and opens an incident with a title, impact, and exclude_from_downtime flag, then posts updates as the state moves from investigating to resolved. The bearer token is injected at call time by your own Jentic One instance. Example prompt: Call POST `/uptime/incidents` with title 'Checkout errors', impact 'partial_outage', and exclude_from_downtime false, then POST `/uptime/incidents/{incidentId}/updates` with state 'identified' and content describing the cause ### Monitor setup from a service inventory Platform teams add monitoring as part of shipping a new service. Creating a Phare monitor needs a name, a protocol of http, tcp, or icmp, the request to send, and between one and six regions, with an optional interval, timeout, success assertions, and confirmation counts before an incident opens or recovers. Example prompt: Call POST `/uptime/monitors` with name 'Marketing site', protocol 'http', a request for https://example.com, regions from the spec's region list, and interval 60 ### Deploy-safe maintenance windows Planned work should not page anyone or count as downtime. A maintenance window needs a title, monitoring_mode, starts_at, and ends_at, and can attach monitors and status pages so visitors see the scheduled work. Windows can be cancelled or completed early, and individual monitors can be paused and resumed around a deploy. Example prompt: Call POST `/uptime/maintenance-windows` with title 'Database upgrade', monitoring_mode, starts_at, and ends_at for the planned slot, then POST `/uptime/maintenance-windows/{maintenanceWindowId}/complete` when the work finishes ### Uptime reporting for stakeholders Monthly service reviews need uptime numbers per service. The project report aggregates uptime statistics for a from and to window, and the per-monitor report breaks out a single monitor, so an agent can assemble a summary without exporting from the dashboard. Example prompt: Call GET `/uptime/reports` with from and to covering last month, then GET `/uptime/monitors/{monitorId}/report` for the lowest-uptime monitor ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/uptime/monitors` | Create a monitor | | POST | `/uptime/monitors/{monitorId}/pause` | Pause a monitor | | GET | `/uptime/monitors/{monitorId}/report` | Get a monitor's uptime statistics | | GET | `/uptime/reports` | Get aggregated uptime statistics | | POST | `/uptime/incidents` | Create an incident | | POST | `/uptime/incidents/{incidentId}/updates` | Post an incident update | | POST | `/uptime/maintenance-windows` | Schedule a maintenance window | | GET | `/uptime/status-pages/{statusPageId}/current-status` | Get a status page's current status | ## Key resources - **Monitors** — HTTP, TCP, and ICMP uptime checks with regions, interval, assertions, and pause and resume - **Incidents and updates** — Incidents with impact, linked monitors, and a timeline of state updates - **Maintenance windows and status pages** — Scheduled work windows and public status pages with current status - **Alert rules, integrations, and projects** — Event routing to integration apps, plus projects and users in the organization ## AI readiness This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use. - **Score:** 63 / 100 - **Maturity:** AI-Aware - **Dimensions:** - Foundational Compliance: 47 / 100 - Developer Experience & Jentic Compatibility: 73 / 100 - AI-Readiness & Agent Experience: 58 / 100 - Agent Usability: 94 / 100 - Security: 60 / 100 - AI Discoverability: 64 / 100 - **View full report:** https://jentic.com/apis/phare.io/phare/scorecard - **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/ - **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview ### Score it yourself Every API in the directory is allowlisted, so you can re-score it with no key required. - **Score your own API:** https://jentic.com/scorecard.md - **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md ```sh npx @jentic/api-scorecard-cli score ``` ## Why Jentic - **Setup:** Wiring Phare by hand means creating a bearer token, sending it in the Authorization header, and adding an X-Phare-Project-Id or X-Phare-Project-Slug header on project operations when the key is organization-scoped. Through Jentic you install once, import Phare from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** Phare puts the monitor id in the URL path (`/uptime/monitors/{monitorId}/pause`), so a rule can pin your agent to one monitor and the operations you pick. You choose the operations it may call, so destructive ones like deleting a monitor or a status page are not included unless you add them. - **Credential handling:** Your Phare token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'open an uptime incident' or 'pause a monitor', and Jentic returns the matching Phare operation with its input schema, including the required fields, so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **UptimeRobot API** — Uptime monitors and alert contacts on the UptimeRobot platform - **Better Stack API** — Uptime monitoring and incident management from Better Stack - **PagerDuty API** — On-call scheduling and escalation for the people who respond to alerts ## FAQ ### What authentication does the Phare API use? The Phare API authenticates with a bearer token (BearerAuth) per its OpenAPI spec, sent as 'Authorization: Bearer '. With an organization-scoped API key, project-level operations also need an X-Phare-Project-Id or X-Phare-Project-Slug header to pick the project. Through Jentic the token is stored by your own instance and attached at call time. ### Can I pause a monitor during a deploy with the Phare API? Yes. POST `/uptime/monitors/{monitorId}/pause` stops checks for that monitor and POST `/uptime/monitors/{monitorId}/resume` starts them again. For longer planned work, a maintenance window attaches monitors and status pages to a scheduled starts_at and ends_at. ### What are the rate limits for the Phare API? The OpenAPI spec does not specify API rate limits. Check the Phare documentation at https://docs.phare.io for current limits. Note that the rate_limit field on alert rules controls how often an alert fires, not how often you can call the API. ### Is there a Phare MCP server? You don't need an MCP server to give your agent Phare. Jentic connects it directly from the API Directory: import it, store your token once, and your agent calls the monitor, incident, and status page operations on demand without loading another server's tool definitions into its context. ### How do I open an incident through Jentic? Search Jentic for 'open an uptime incident', load the POST `/uptime/incidents` operation, and execute it with the required title, impact, and exclude_from_downtime fields, optionally linking monitors. Then post progress with the incident updates operation. To run it on your own infrastructure, install Jentic One from its GitHub repo. ### Can I limit what my agent is allowed to do with the Phare API? Yes. Write a rule that allows GET `/uptime/monitors/{monitorId}/report` plus the pause and resume operations for one monitor id, and the agent can read that monitor's uptime and pause it around a deploy while other monitors and status pages stay untouched. Every call it makes is logged for review.