Privacy policy
Last updated 28 August 2026
Silent Fail is operated by Metrix Technologies Limited, which is the data controller for everything described here and the company to contact about any of it.
This describes what Silent Fail actually stores, taken from the database schema rather than from a template. It is meant to be checkable: every field named below is a real column, and the reason next to it is why the product cannot work without it.
What we never see
Not a courtesy, a consequence of the design. A monitor works by your automation making one HTTP request to a URL. We record that the request arrived and when. We do not read the request body, and there is no column to put it in.
So the contents of your workflows — the invoices, the customer records, the messages, whatever the automation actually moves around — never reach us. We are not connected to your n8n, Make or Zapier account. We have no API key of yours, no OAuth grant, and no way to look inside a workflow or to run one. All we know is that something pinged, and when.
Your account
| What | Why it exists |
|---|---|
| Identifies the account, and is where alerts are sent. There is nowhere else for an alert to go. | |
| passwordHash | A scrypt hash, never the password. It cannot be reversed into the password you typed. |
| timezone | An IANA zone such as Europe/London, so a schedule of “daily by 09:00” means 09:00 where you are rather than in UTC. |
| plan | Which plan the account is on, which sets the monitor limit. |
| emailVerifiedAt | When you confirmed the address by following the emailed link, or empty if you have not. Until it is set, monitors cannot be created — an address we cannot reach is a monitor whose alerts go nowhere. |
| billingCustomerId, billingSubscriptionId | Paddle's identifiers for your subscription. No card number, expiry or billing address ever reaches us. |
| createdAt, updatedAt | When the account was opened and last changed. |
Your monitors
| What | Why it exists |
|---|---|
| name | Whatever you called the monitor. It appears in the alert subject. |
| slug | The unguessable token in the ping URL. Public by necessity — your automation sends it — which is why it identifies a monitor and nothing else. |
| scheduleKind, intervalMin, dailyHour, dailyMinute, gracePeriodMin | How often a ping is expected and how much lateness is tolerated before an alert. |
| status, lastPingAt, alertSentAt | Whether the monitor is up or down, when it last pinged, and whether an alert has already gone out for the current outage. The last one is what stops a second email. |
| disabledAt | When the monitor was switched off, or empty if it is being watched. Set when a plan change leaves an account over its limit, or when you choose which monitors stay on. It is never a deletion — the row and its history stay. |
Pings
One row per ping received, which is the raw material for every decision the checker makes.
| What | Why it exists |
|---|---|
| receivedAt | The instant the ping arrived. This is the measurement the whole product is built on. |
| method | GET or POST, so an unexpected method is visible when you are debugging a setup. |
| sourceIp | The address the ping came from, shown on the monitor's page. It is how you tell your own workflow's pings from something else hitting the URL. |
| userAgent | What identified itself as making the request, for the same reason. |
Alerts we sent you
Every alert is logged, successful or not. This is the audit trail behind the promise that one outage produces one email, and it is also what lets a question about a past alert be answered from a record rather than from memory.
| What | Why it exists |
|---|---|
| type, channel, target | Whether it was a down alert or an all-clear, that it went by email, and to which address. |
| subject, body | The text of the message as sent. It is the record that answers “what exactly did you tell me, and when”. |
| provider, ok, error | Which mail path handled it and whether delivery succeeded. An alert that failed to send is kept, not hidden. |
| sentAt | When the attempt happened. |
Sessions, password resets and email confirmation
| What | Why it exists |
|---|---|
| Session id and expiry | One row per signed-in session, so signing out and a password change can end them. Deleted when they expire or when you sign out. |
| Password reset token hash | A SHA-256 of the token in the reset link, never the token. Reading the database cannot produce a working link. |
| Email verification token hash | The same construction as the reset token, and stored the same way: a SHA-256 of the link we emailed, never the link itself, single use and with an expiry. |
| Request IP on a reset or verification | Recorded against the request so a burst of them can be investigated. Never shown to whoever asked. |
Cookies, by category
Strictly necessary. Two cookies. sf_session holds a session identifier and nothing else — no personal data is encoded in it. It is HttpOnly so page scripts cannot read it, SameSite=Lax so it is not sent from other sites, Secure in production, and lasts 30 days or until you sign out. Without it there is no way to stay signed in. sf_consent records your answer to the analytics question below, for six months. The cookie that remembers a refusal has to be exempt from needing consent, or the refusal could not be honoured and you would be asked again on every page.
Analytics, only if you allow it. Google Analytics 4 sets _ga and a per-property _ga_* cookie to count visits and see which pages people arrive on. It does not run until you have actively said yes: before that the script is never loaded, so no _ga cookie can be written at all. The gate is that we do not load it, rather than loading it and asking it to behave.
Declining is one click, exactly like accepting, and turning analytics off later also expires the cookies it already set rather than only stopping new ones. You can change your mind at any time on the cookies page, which is linked from the footer of every page.
Even with analytics allowed, it is not loaded on any page whose address contains a token — a password reset or an email confirmation link — because a page-view beacon reports the address it is on, and that would hand a working credential to a third party.
Payments. Opening the checkout loads Paddle, which sets its own cookies to run the payment flow and detect fraud. This happens only if you open the checkout, and those cookies are governed by Paddle’s own policy.
Who else processes it
A short list, because the stack is small. Each of these has access only to what its job needs.
| What | Why it exists |
|---|---|
| Railway | Runs the application and hosts the PostgreSQL database. This is where everything above is stored. The region is US East. |
| Cloudflare | DNS and the proxy in front of the site, so it sees request metadata such as your IP address in transit. |
| Paddle | Merchant of record for subscriptions. They take the payment and hold the card details; we hold their identifier for you. |
| Google Analytics | Aggregate traffic measurement, and only with your consent. Nothing is sent to Google unless you have allowed analytics, and it is never loaded on a page whose address carries a token. |
| An SMTP relay | The mail server configured to deliver alerts handles the address and the message on the way to your inbox. |
We do not sell your data, we do not share it with advertisers, and there are no third-party trackers beyond the analytics named above.
How long it is kept
Monitors, their pings and their alert log stay for as long as the monitor exists. Deleting a monitor deletes its pings and its alert history with it. A monitor switched off by a plan change is not deleted and keeps everything. Sessions disappear when they expire, and every session on an account is deleted the moment its password changes. A reset token becomes unusable an hour after it is issued, a verification link after 24 hours, and both are marked spent the moment they are used.
There is no automatic pruning of old pings yet. If that changes, this page changes with it.
Deleting your account
Email contact@silentfailapp.com from the address on the account and it will be deleted. Being straight about it: there is no self-service delete button yet, so this is a manual request rather than a click.
The deletion is complete rather than a flag. Removing the account removes its monitors, every ping and alert record belonging to them, all sessions and any outstanding reset or verification tokens, because the database is set up to cascade. What we cannot delete is Paddle’s own record of a payment, which they are required to keep for tax purposes.
You can also ask for a copy of what is stored about you, or for something to be corrected, at the same address.
Changes
The date at the top of this page is the last time it changed. If a change materially affects what is collected or who processes it, the account address gets an email rather than a quiet edit.
Questions about any of this go to the same address as everything else.