Status
Dependency checks
| Check | Role | State |
|---|---|---|
| postgres | Reports, scores, publication history | checking |
| redis | Rate limiting, sessions, cached lookups | checking |
The endpoint is unauthenticated, and driver errors embed internal hostnames and database users. Callers get the dependency name and nothing more; the detail is logged server-side.
curl -s api.vspam.org/health curl -s api.vspam.org/health/ready
Readiness returns a per-dependency checks map and a degraded list when something is wrong.
Mail keeps flowing. The vspam-agent policy service always fails open on an API error or timeout — a blocklist that stops mail when it cannot be reached is worse than no blocklist.
smtpd_policy_service_default_action = DUNNOCurrent report workflow
Report status transitions use weighted community review and manual actions. Feed publication and blocking recommendations also consider score-aware policy, but the workflow thresholds below remain the current report-status rules.
| Condition | Workflow status |
|---|---|
| 1 Trusted reporter confirms | confirmed |
| 2 Contributor+ reporters confirm | confirmed |
| 3 community members confirm | confirmed |
| 1+ confirms (below threshold) | under_review |
| Majority rejects (2+ total votes) | false_positive |
Scoring policy
Core publication decisions are deterministic and explainable. The main evidence stages are:
Convert submissions into a stable artifact. Domains are the primary phishing artifact; URL path and query detail are kept only as short-lived enrichment evidence.
Resolve records, registrar, age, ASN, hosting provider, redirects, and related domain context for each artifact.
Score direct evidence, historical observations, domain risk, IPv6 neighborhood context, and ASN reputation with explicit reasons and confidence.
High-confidence domains and exact hosts can be listed for blocking. IPv6 prefix and ASN feeds are published primarily as watch or reputation context.
Reporter trust, voting, manual review, and delist requests help resolve ambiguous cases and prevent persistent false positives.
About vspam.org system status
This page checks the API's own liveness and readiness probes once on load, with a manual "Check again" to re-run them, and shows exactly what those probes cover — nothing is inferred or simulated.
Liveness vs. readiness
- GET /health — liveness. Answers only whether the API process is running and can serve HTTP. It checks no dependency, by design: restarting the API because Postgres blinked would turn a recoverable outage into a crash loop.
- GET /health/ready — readiness. Verifies exactly two dependencies, postgres and redis, each bounded by a 2-second timeout. Any failed check flips the response to
degradedand returns503so a load balancer stops routing traffic here. Failure detail is logged, never returned in the response.
Not health checks
The DNSBL zone and the feed publisher are not probed by /health/ready — this page presents them by their publication cadence instead of inventing a status for them.
Incident reporting
If you are experiencing issues not reflected on this page, contact support@vspam.org. For integrators, see the API documentation to wire these same endpoints into your own monitoring pipeline.