Status
Measured by the service itself and read straight from its own request log. Nothing on this page is a promise — it is what actually happened. Refresh for the current numbers, or read /status.json.
Operational
| Database | reachable |
|---|---|
| Renders in flight | 0 active, 0 queued |
| This instance has been up | 4d 20h (since 2026-10-04 21:07 UTC) |
PDFMint runs as a single service. A deploy restarts it, which resets the uptime figure above — it measures this process, not the service's history.
Last 24 hours
| Documents produced | 27 |
|---|---|
| Succeeded | 27 |
| Refused before rendering | 0 — a bad option, a page that answered 4xx, a selector that never appeared. The credit is refunded. |
| Failures on our side | 0 |
| Success rate, excluding refused requests | 100% |
| Success rate, counting everything | 100% |
| Render time, median | 835 ms |
| Render time, 95th percentile | 3,300 ms |
| Render time, slowest | 9,692 ms |
Bars count failures on our side only, not requests we refused. One bar per hour over the last 24 hours, tallest bar = 7 documents. Red means at least one document failed in that hour. Hover a bar for the exact count.
Last 7 days
| Documents produced | 97 |
|---|---|
| Refused before rendering | 0 |
| Failures on our side | 0 |
| Success rate, excluding refused requests | 100% |
What we do not have
Being straight about it, because you are about to depend on this:
- No third-party uptime monitor yet. The numbers above are self-reported, and they count only this deployment — a development machine sharing the database used to show up here.
- No SLA, and no SOC 2 report.
- One instance, one region (Frankfurt). A deploy causes a short restart.
- Render failures refund the credit automatically, so a bad minute does not cost you documents.
If something is broken, open an issue at github.com/fstandhartinger/pdfmint/issues.