Reference · built on requestOperator by FibricIT & reliability

Uptime Response

When an uptime check fails, proposes the page to whoever is on call, the public incident, and the rollback of the deploy before it.

Request accessPricing ↗

About

A failed check at 02:00 should not depend on who is awake. Uptime Response reads Synthetic test results from Datadog, HealthCheckStatus for each Route 53 health check in CloudWatch, and Health Checks on your Cloudflare zones. It reads who is on call from PagerDuty's oncalls endpoint for the service that owns the failing endpoint, and the deployments GitHub recorded for that service in the hours before.

When a check fails and stays failed past the threshold you set, it drafts three things at once: a PagerDuty alert to the on-call, a Statuspage incident with the affected component set to the right status, and, if a deploy landed just before, a deployment request for the previous ref. The on-call approves each one from the page itself. A flapping check, or one already covered by an open incident, produces nothing new.

This is a reference listing. It documents what Fibric would read from Uptime Response and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Synthetic test results from GET /api/v1/synthetics/tests/{public_id}/results in Datadog, with result.passed, check_time, and status per location
  • HealthCheckStatus and HealthCheckPercentageHealthy in the AWS/Route53 namespace, sent to CloudWatch once a minute per HealthCheckId
  • Health Checks on each Cloudflare zone through /zones/{zone_id}/healthchecks and their status notifications
  • Who is on call now for a service through GET /oncalls in PagerDuty, and open incidents on that service
  • Deployments and deployment_status events from GitHub for the repositories mapped to each endpoint
  • Components and open incidents on your Statuspage page, so a second alert joins an incident instead of opening another

Proposed actions

  • Target capability: propose a trigger event with a dedup_key through the PagerDuty Events API v2 to the service that owns the endpoint
  • Target capability: propose a Statuspage incident with status investigating and the affected component set to degraded_performance, partial_outage, or major_outage
  • Target capability: propose a deployment of the previous successful ref through the GitHub Deployments API when a deploy preceded the failure
  • Target capability: propose a Statuspage incident update to monitoring or resolved once the check passes again
  • Target capability: propose a note on the PagerDuty incident with the check history, the deploy, and the actions taken

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Page the right person with the deploy attached

    Two Datadog Synthetic locations fail the checkout test past your threshold. The operator finds the deployment that landed shortly before and proposes a PagerDuty trigger whose body names the ref and the failing locations.

    With Datadog, GitHub, PagerDuty

  • Open the public incident without the scramble

    HealthCheckStatus for the API drops to 0 across checkers. Uptime Response proposes a Statuspage incident with the API component set to major_outage and the text prefilled; the on-call edits and approves.

    With Amazon CloudWatch, Statuspage

  • Roll back and close the loop

    A Cloudflare Health Check on the origin turns unhealthy after a release. The operator proposes a deployment of the previous ref, and once the check is healthy again proposes moving the incident to resolved.

    With Cloudflare, GitHub, Statuspage

Requirements

  • At least one uptime source: Datadog Synthetic tests, Route 53 health checks in CloudWatch, or Cloudflare Health Checks on a paid plan
  • A PagerDuty service per endpoint with an Events API v2 integration key, and a REST token that can read oncalls
  • A Statuspage page with a component per public-facing service and an API key for it
  • A GitHub App with deployment write access, and a map from each endpoint to the repository and environment that deploys it
  • A failure threshold per check, consecutive failures and locations, set by you
Authentication
Uptime Response has no identity of its own. Datadog, CloudWatch, and Cloudflare are read, and PagerDuty, Statuspage, and GitHub are written, through their connectors and the keys you gave them.

Limits

  • Statuspage allows one request per second per API token on a rolling window; a burst of checks is queued, not dropped.
  • Route 53 publishes health check metrics once a minute and keeps them for two weeks; longer history comes from your own store.
  • Cloudflare Health Checks are not available on the Free plan, and the number of checks depends on the plan.
  • It proposes a page, an incident, and a redeploy of a known ref. It does not restart services, change DNS, or scale anything.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Uptime Response ↗

Questions and answers

What does the on-call approve?
Up to three proposals per failure: the page, the public incident, and the rollback. Each shows the check results by location, the on-call it resolved, and the deploy it found. The on-call can approve one, edit the incident text, or dismiss all three.
What is left after the incident?
A timeline: the check results that crossed the threshold, each proposal with its approval and the API response, the Statuspage incident ID, the dedup_key of the PagerDuty event, and the deployment ID if a rollback ran.
Will it page or roll back on its own?
No. Every page, incident, and deployment request is held until a person approves it. If no one responds, the check keeps being read and the proposal stays open; the operator does not escalate by itself.
Ask about Uptime Response

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy