Watch the chain, not the endpoint: APIs, queues, functions and crons on AWS, Azure and GCP with no agents to install, and flows that tell you the exact step where the order broke.
3 URL or cron monitors at no cost on every plan. A package adds health endpoints, flows and your cloud resources, watched through the connection you already have.
Order → invoice flow
Last run: broken at step 2
Trigger · SQS queue
orders-in
Sent with its traceId
Step 1 · line in the logs
/aws/lambda/process-order
Arrived
1.2 s
Step 2 · DynamoDB item
orders
Did not arrive within 2 min
Step 3 · S3 object
invoices/2026/
Not checked
The order reached the queue and the function processed it, but it never reached DynamoDB: the failure is between the function and the table.
5
monitor types, from a URL to an end-to-end flow
3
clouds watched without installing agents: AWS, Azure and GCP
2
regions confirm a URL is down before alerting
6
alert channels, with quiet hours and a re-alert
In serverless almost nothing fails at the front door. It fails behind it: a queue that backs up, a function that retries silently, an event nobody consumes.
The endpoint answers, the dashboard stays green and you hear about it from a customer. The queue has been growing for hours, the dead-letter queue is full and nobody checked the age of the oldest message.
We watch the URL, the state of each component and the resources behind it. A test flow walks the chain and tells you which step did not arrive, how long each one took and what the outage cost.
Sample data.
Start with what you have and add depth when you need it. Monitors share the organization’s quota, whatever the cloud; flows have their own.
A URL with assertions on status code, latency, header, body or JSONPath. Authentication with bearer, basic, API key or your AWS, Azure or GCP account identity.
GET /orders · 200 · 142 ms
Reads your health endpoint and splits it by component: a slow database leaves the service degraded, not down.
database: pass · cache: warn → degraded
Functions, queues, tables, APIs and workflows on AWS, Azure and GCP, read through your connection: errors, throttles, oldest message age and dead-letter queue.
orders-in · oldest message 4 h old
A URL your cron or job calls, every minute or once a month (up to 35 days). If it doesn’t call in time, you get an alert.
nightly-billing · last check-in 3 min ago
Fires a test transaction and checks that it reaches every step. It tells you the exact step that broke and how long each one took.
orders-in → logs → orders ✕ → invoices
A flow sends a test message with a traceId and checks it reaches every step within its deadline. Your code only has to keep that id in the item key, the object or the log line, and recognise the test so it doesn’t charge, send emails or create real orders: @aaa-sentinel/health (Node.js) and aaa-sentinel-health (Python) handle each with one line.
On AWS and Azure you choose where the test enters and we follow the real connections in your account (queues, functions, rules and subscriptions) to suggest the steps and their deadlines.
A message in the queue, an invocation, an event or a request, tagged with its traceId and its W3C traceparent.
Looks for the traceId where it should appear, with a deadline per step, and records how long it took since the previous one.
If a step does not arrive, the flow goes down with that step marked, and the alert gives its number and its name: you know whether to look at the function, the queue or the table.
On AWS it starts with SQS, Lambda or EventBridge; on Azure, with Service Bus or Event Grid; on GCP, with Pub/Sub, Cloud Run or Eventarc; and on any of them, with an HTTP call. Each step is checked against what your chain leaves behind (an item, a document, an object or a blob), a log line or a call to our URL.
We read health+json, Spring Boot Actuator, ASP.NET Core Health Checks and Kubernetes endpoints as they are. Starting from scratch, @aaa-sentinel/health for Node.js or aaa-sentinel-health for Python builds the response in three lines.
health.ts
import { runHealthChecks } from '@aaa-sentinel/health'
export const handler = () =>
runHealthChecks({ database: () => db.query('select 1') })A component in "warn" leaves the service degraded, not down: it shows on the status page and goes out as a webhook event, without waking anyone up.
A single failure wakes nobody up. Each monitor moves through these states and only "down" opens an incident and alerts. New monitors observe for 24 hours before alerting; for URLs and crons they also suggest thresholds.
Up
Checks pass.
Suspect
One failure on a URL or health endpoint. No alert yet.
Confirming
A URL or health endpoint is checked from a second region; a resource or a flow, by waiting for the failure to repeat.
Down
Confirmed: the incident opens and alerts go out through your channels.
Recovering
Passing again. The incident closes once it holds.
Alerts go by email, Slack, Microsoft Teams, PagerDuty, Jira Service Management or webhook, and open a ticket in Jira or Linear, using the same alerting engine as your cost alerts. Monitoring has a policy of its own: quiet hours, maintenance windows and a re-alert if it is still down.
What happens when something goes down: what it costs, how it gets fixed, who hears about it and where you see it.
Each incident carries its timeline, who is on it, its notes and what it cost: the value of a minute of downtime that you set, in your currency, on the same platform as your cloud spend.
On Business, when the cause has a fix, the incident offers it and it runs once approved: move the dead-letter messages back to their queue, stop the failing rule or Logic App, or raise the reserved concurrency a function already has. Stopping and raising concurrency can be undone.
Group monitors into services that depend on each other. Their status comes from the worst component or a quorum, alerts are sent per service and each one has its own health+json endpoint in the API.
Public, or private with a secret link, in the language you choose for each page. Public ones also on your own domain (such as status.yourcompany.com) with its certificate, plus status.json and an Atom feed. On Business they carry your logo and name.
On Business, each monitor can be assigned to a client: their status page, their own signing secret if you want one, their monthly availability report as a PDF with your brand, which can be emailed to them every month and is also part of the client report, and the monitor count to rebill it.
Turn your CloudWatch alarms, Route 53 health checks, Azure metric alerts and availability tests, and GCP uptime checks into monitors, with no new permissions.
Status, duration and availability of each monitor, plus open incidents: for Prometheus, Grafana Alloy or the Datadog agent, or sent over OTLP to New Relic, Grafana Cloud or your collector.
Outages, recoveries and incidents, signed, in our format or as CloudEvents.
Each public status page publishes its machine-readable state and a feed for readers and Slack.
No other account, invoice or dashboard to check: on the same platform as your cloud spend and your security.
URLs as often as every minute, with assertions, authentication and confirmation from another region; crons that alert you when they miss their check-in.
Flows that run through your chain with a traceId and tell you which step broke.
Queues, functions, tables, APIs and workflows on AWS, Azure and GCP, through the connection you already have.
Timeline, who is on it, notes and what it cost, with alerts over six channels.
Public, on your own domain if you like, or private behind a secret link.
A monthly PDF, also by email; on Business, one per client with your brand.
How it is billed
€49
per pack per month, on Pro and Business · €39 from the 4th
€1.96 per monitor a month; €1.56 from the 4th pack
Get started| What is included | Without a pack | With a pack |
|---|---|---|
| Monitors | 3 | 25 per pack |
| What they watch | URLs and crons | Also health endpoints and your cloud resources |
| End-to-end flows | Not included | 3 per pack |
| Status pages | Not included | 1, plus one per active client on Business |
| Plans | All, Free included | Pro and Business |
| Price | No cost | €49 a month; €39 from the 4th pack |
Probes run in our account. In yours you’ll see metric reads (on AWS up to about USD 0.20 per resource per month at 10 minutes, twice that at 5; on Azure and GCP it usually fits in the free tier), the monitors’ requests to your API and, for flows, what your chain runs with each test and the log searches.
3 monitors at no cost to start. €49-a-month packs when you need more.