How to Get Alerts When a SaaS Vendor Reports an Outage

Follow vendor incidents, check your own endpoints, and catch missed job check-ins. Choose the monitoring signal and alert route that fit the failure you need to detect.

By Statusfield Team · Engineering4 min readUpdated October 31, 2026
On this page

A customer reports a failed payment. Your hosting provider says operational. Your nightly reconciliation job has not produced a file. These problems need different checks, even when they affect the same product.

Use vendor monitoring for incidents a provider reports, uptime monitoring for responses from your own website or API, and heartbeat monitoring for jobs that stop checking in. Bring those signals together so the person investigating can see what changed.

What a vendor outage alert tells you

Vendor monitoring follows the provider's published status. Choose the services, supported components and regions you depend on, then decide which reported changes should reach your team.

An alert can include an affected component, reported severity and incident details when the vendor provides them. That gives you context for an investigation without opening every status page separately.

It does not establish that your own account is affected. A provider can also report operational while your application fails or while an incident remains unreported. Aggregating status pages does not remove the provider's reporting delay.

What to do when the vendor is green but your site fails

Check the URL your users or applications depend on. An uptime monitor makes scheduled requests to a public HTTPS endpoint and compares the response with your rules.

In Statusfield, those rules can include an expected status code or range, a slow-response threshold, a timeout, and text or JSON response-body checks. A slow valid response can be degraded. An unexpected status, failed body check or timeout can be an outage.

For example, a health endpoint returning HTTP 200 with the wrong JSON result should not pass merely because the request completed. Choose a body rule that represents the condition you need to observe.

A single HTTP request does not test a complete login or checkout. Keep application logs and workflow tests for those questions. See website and API uptime monitoring.

What to do when a job fails without an error alert

A job that never runs cannot send its own failure notification. Have it send a heartbeat after its work and success checks finish. An external monitor can then notice that the expected signal is missing.

In Statusfield, set an expected interval and a grace period. After the first check-in starts monitoring, a missed deadline can trigger your configured alerts. Send to the check-in URL with /fail appended when the job can report a known failure.

A backup command's success and a usable backup are different checks. Verify the outcome you care about before sending success, and test restores separately. See heartbeat examples and current access terms.

The same pattern can watch a scheduler or monitoring process: send the signal after it completes its checks, and choose an alert destination that remains available if that process fails.

Set up an alert route your team can use

  1. Choose one recurring responsibility. Start with a vendor component, public endpoint or scheduled job whose failure matters to your work.
  2. Choose the right monitor. A vendor report, an HTTP response and a job check-in answer different questions. Combine them where useful.
  3. Set the rules. Select relevant vendor statuses, define endpoint response rules, or set a job's expected interval and grace period.
  4. Connect a destination. Send the selected events to the people who can investigate. Available email, chat, webhook and on-call destinations depend on your plan.
  5. Verify the setup. Send a labeled destination test and confirm receipt. Check the saved monitor rules too. Use a disposable endpoint or job when testing failure and recovery behavior.

Do not require a real outage to learn that an alert is going to the wrong channel. The quick-start guide walks through each monitor type and its setup.

When a shared monitoring workspace is useful

Native vendor subscriptions may be enough when you follow a few services and their notifications reach the right people. A shared workspace becomes useful when component choices, destinations and updates are scattered across vendors and inboxes.

Statusfield brings official vendor reports, public HTTPS checks and job check-ins into one workspace. Your team still investigates the cause and confirms recovery. Monitoring gives that work a starting point; it does not guarantee earlier detection than a vendor or customer.

Check vendor coverage, compare plans, and start with a setup you can verify. Trial eligibility, monitoring capacity and destination limits are listed on the pricing page.

Keep your vendors in view.

Choose from 7,000+ services, follow the components you use, and configure alerts for your team.

Try any paid plan for 30 days, no credit card required. Free trial for first-time customers.