Loading…
Short answers. The product and developer pages have the long ones.
It watches the public sources of the services your software depends on (status pages, changelogs, release feeds, security advisories, vendor email), turns what they publish into one kind of event, and tells you about the ones that matter: at once, in a digest, or not at all, by rules you can read.
No. It does not probe your systems or the vendor’s. It reads what vendors publish about themselves. Pair it with your own monitoring; it tells you the upstream side of the story.
No, but the fastest setup uses a coding agent that can read your repository. Without one you can add dependencies and custom sources by hand in the app.
Never. Your agent reads the repository with the access it already has and sends only the dependency list. The platform never asks for repository access.
Not today. Classification, priority, deduplication and routing are rules, and every result shows the rule. An optional bring-your-own-key analysis is planned, off by default.
Claude Code with one command, and any client that speaks MCP over HTTP (Cursor, Windsurf, custom clients). Anything that can make an HTTPS request can use the REST API.
With the default key: projects, dependencies, sources, sender rules, incident notes and review items. Rules need rules:write; destinations and ticket systems need destinations:write. Everything it does is in the audit log.
It can push an incident to a ticket system you set up, and its instructions say to do so only when you ask. It cannot add a ticket system without a deliberate grant.
Some vendors only notify by email. The address is where you subscribe. The product checks who really sent each message, so an address that leaks cannot be used to page you.
Not unless you allow it for the project, and then only when the mail was verified for the vendor’s own domain and the link stays on an allowed host. Otherwise the link waits for you under Action needed.
Unverified mail becomes a normal-priority event at most and never alerts immediately. Risky mail is quarantined with the reasons until you release it or trust the sender.
The raw message for thirty days by default, then it is dropped; the extracted text and a header subset stay with the event. A project can switch raw retention off entirely or delete stored mail at any time.
Because the vendor’s severity says nothing about your deployment. Impact is marked by a person or your agent, with a note naming the evidence. The API refuses a claim of impact without one.
Resolved is the vendor’s word. An incident stays open for you until you or your agent clear it, so nothing you have not looked at disappears.
Mute it for a day or a week from any incident, or set a lasting preference: ignore categories, sources, named senders, or anything below a severity. The product can suggest preferences from what you marked irrelevant.
Daily at 08:00 UTC unless you set a schedule per project: an hour, a time zone, daily or weekly.
Jira Cloud, Linear, GitHub Issues, and incidents on your own Atlassian Statuspage. You can also copy the summary as text or Markdown.
In a Postgres database at Supabase, in the region chosen at creation; raw mail at Cloudflare for its retention period. The security page lists every provider.
Yes. Archive a project (purged after thirty days), delete a workspace (immediate), or delete your account (workspaces you alone own go with it).
Nothing up to 20 dependencies, with published monthly meters for mail, events, webhook deliveries and stored mail. At a cap, events are still stored and only urgent incidents are delivered until the month rolls over.
The quickest answer is to sign in and ask your agent to set up one project.