← All legal documents

Service Commitment

Last Updated: August 27, 2026

This Service Commitment describes how fast Earnesty (“the Service”), operated by Know Reply Inc. (“Know Reply”, “we”, “us”), verifies posts, how available we aim to keep the Service, what we do when we miss, and what is outside our control. It applies to every APP on every plan, including the free plan, and it is part of the Terms of Service. It is written to be read by your USERs too: they are the people watching a post sit in “pending”, and they are entitled to know what that wait does and does not mean.

1. The most important thing: a post’s earnings do not depend on when we get around to looking

A Claim’s base value is fixed at your post’s timestamp and never changes with how long Verification takes. The moment a USER posts, that number is locked against the terms snapshot in force at that moment. Ninety seconds or eleven hours later, the base value we settle is the same number. There is no reduced rate for a slow queue, and no plan on which a USER earns less because their APP pays us less.

The reply bonus works the same way. It is settled once, five days after the post’s own timestamp — not five days after we verified it — so a post that waited in our queue is settled on exactly the same schedule as one we saw immediately. The bonus is counted in distinct replying accounts, never in raw replies: ten replies from one account count as one. It scales along a curve that rises quickly at first and then flattens toward a maximum the Product sets, so a post that drew real conversation earns more than one that drew a little, and nothing ever earns more than that maximum. At settlement the post must still be public and still carry the Partner Tag; if it is not, there is no bonus.

So the whole of what a post earns — the base value and the bonus alike — is settled against the post, not against our latency. Speed still matters: a USER who has posted wants to see it counted, and section 2 treats that as a floor rather than something to sell. But it is a matter of experience, not of money.

There is one limit on that, and we would rather state it than let you discover it: a settlement delayed past the platform search window it depends on cannot be recovered. Section 6 explains what that window is, why settlement runs well inside it, and what we do if we ever run out of that margin.

2. Fast verification is a floor, not a feature

Verification speed is visible to end USERs. A USER who posts and then watches nothing happen for two days does not conclude that their APP chose a cheaper plan — they conclude that the earned tier is broken. That impression lands on the APP, on Earnesty, and on the whole idea of earning a tier by posting.

So we do not sell speed by degrading it. Verification is fast on every plan, including the free plan, and:

• Verification and delivery are never gated by billing state or plan. Only speed and on-demand depth are priced. Every plan gets full mechanical verification and, on success, a full reward-delivery instruction to the APP.
• The one exception is integrity, never billing or editorial judgment. We may place Verification for an account on hold while we investigate suspected fraud or abuse under the Acceptable Use Policy. A hold is an abuse control: it is not applied for non-payment, for a plan level, or because we dislike what a post says, and a Claim held during an investigation is still valued at its post’s timestamp.
• Every Claim includes one free “check now” on every plan. A USER who has just posted can ask us to look immediately, without waiting for the next polling cycle and without their APP paying for it.
• A downgrade, a cancellation, or a lapsed payment does not slow verification of Claims already issued. Those Claims are evaluated and settled under the wind-down terms in the Terms of Service.

3. Why we do not publish latency targets

Most service commitments lead with numbers — verification within N minutes, discovery within N hours. We do not, and the reason is the design rather than reticence.

Latency does not cost a USER anything here. A Claim’s base value is fixed at the post’s timestamp. The reply bonus settles against that same timestamp. So the number a USER earns is already decided before we look, and looking sooner or later cannot change it. A published latency target would be measuring something that does not affect what anyone is paid.

What a target would do is create a new way to be in breach over a delay that costs nobody anything — and it would do it largely on other companies’ behalf, because most of our latency risk sits in Supported Platform APIs we neither control nor can hedge. We would rather commit to fewer things and mean all of them.

So this document commits to structure, not to speed. Section 2 is the commitment: full mechanical verification and full reward delivery on every plan including free, never gated by billing state, with a free on-demand check on every Claim. Those are promises we control entirely. We hold ourselves to internal latency targets, we build and staff for them, and we report what actually happened on the status page — but we do not turn them into contractual numbers that would pay out on an outage at X.

If you need a contractual latency commitment for procurement reasons, raise it during an enterprise agreement and we will discuss it against your actual requirement.

4. What a paid plan actually buys

Plans differ in speed and in on-demand depth, never in whether a post gets verified or a reward gets delivered:

• Unlimited on-demand “check now.” Every plan gets one free check per Claim. Paid plans can check as often as the platform’s rate limits allow.
• Priority processing. Paid work is processed ahead of free-plan work when both are waiting.
• Near-real-time modes where the platform supports them. Where a Supported Platform offers webhooks or an equivalent push mechanism, paid plans can be wired to it instead of waiting for the daily sweep. Where a platform offers no such mechanism, no plan can have it, and we will not imply otherwise.

See the Supported Platforms schedule for which platforms currently support which modes.

5. What this commitment does not cover

We are honest about the parts of the loop we do not own. The targets in section 3 exclude time and unavailability caused by:

• Supported Platform API outages or degradation. If X’s search API is down, we cannot find posts. We can only queue and retry.
• Rate limiting by a Supported Platform, including limits applied to our app-level access, and including limits that tighten without notice.
• Platform policy, pricing, or API changes, including a platform removing an endpoint, changing access tiers, or restricting what public data developers may read.
• Posts that are not publicly visible at the time we look — protected accounts, deleted posts, posts restricted to followers or to a circle, and posts removed by the platform. We verify public posts; a post we cannot see cannot be verified.
• Posts that fail verification on the merits — a missing Partner Tag, a missing @mention, an unbound author, or a platform post ID already credited once. That is a working system returning a correct answer, not a delay.
• Delays inside the APP’s own systems, including the APP’s endpoint being unreachable when we deliver a reward instruction, or the APP’s own Reward grant taking time.
• Scheduled maintenance announced in advance on the status page, and emergency maintenance where advance notice is not possible.
• Force majeure and other events outside our reasonable control, including cloud infrastructure outages.

None of these change what a post earns. A post delayed by a platform outage is still valued as of its own timestamp, whenever we finally see it, and its reply bonus is still settled five days after that same timestamp rather than five days after we caught up.

6. What we do when we miss

• We tell you. Material degradation and incidents are posted to the status page while they are happening, not after, and we do not quietly close an incident without saying what it was.
• We publish a post-incident note for any incident that materially affected verification for more than four hours, including what happened, what we did, and what we changed.
• We re-run what we missed. Verification work delayed by an incident is queued and completed, not dropped. Because both the base value and the reply-bonus settlement are keyed to the post’s own timestamp, catching up restores them in full — a delayed settlement pays exactly what a timely one would have.
• Nothing is lost on the USER side. An outage on our side never reduces what a Claim is worth, and never changes what its reply bonus is settled against: both are keyed to the post’s own timestamp rather than to ours. A settlement we recover late still counts the conversation the post drew.
• One honest limit on recovery. Supported Platforms only let us search recent conversation, and on X that reach is seven days deep and cannot be extended at any price available to us. A settlement delayed past that window cannot be recovered by any retry, because the replies are no longer visible to us. That is precisely why settlement runs five days after the post rather than seven: it leaves two full days of margin for us to catch up in. If we ever exhaust that margin on a post, we will say so on the status page rather than quietly settle it short.

We do not offer service credits, and that is a deliberate position rather than an omission. The usual purpose of a service credit is to compensate for value lost during downtime — but here no value is lost. A Claim’s base value and its reply bonus are both settled against the post’s own timestamp, so a delay does not reduce what anyone is paid. A credit would be compensating for inconvenience, which is real but is not what the mechanism is for. Most of our latency risk also sits in platform APIs we do not control, and a credit regime would pay out on other companies’ outages.

What we offer instead: if we miss on availability in a way that materially affects you for two consecutive months, you may terminate without penalty and receive a pro-rated refund of prepaid, unused subscription time. We also make goodwill credits case by case, and enterprise agreements can negotiate their own terms. These remedies sit alongside your rights under the Refund Policy and the Terms of Service.

7. The status page

We publish current Service status and incident history at status.earnesty.app.

It is checked from your browser, not ours. The page holds no monitoring of its own and makes no claim about what we believe is happening — it asks the Service directly, from where you are standing, and shows you the answer. A status page reporting a vendor’s own opinion of its health can be wrong in both directions: green while a whole region cannot reach it, red while everyone is fine.

It is hosted apart from everything it reports on. Static files on separate infrastructure, sharing nothing with the systems that serve the Service. A status page that goes down with the thing it reports on is worse than no status page, because its silence reads as reassurance.

We do not publish latency percentiles there, for the reason given in Section 3: what a post earns does not depend on when we get to it, so a number measuring our speed would not be measuring anything you are owed.

Two different pages, two different jobs:

• The public system status page tells everyone whether Earnesty is working right now.
• A USER’s status page (for example https://acme.earnesty.page) tells one USER what their Claim is worth, how many credited posts they have left this month and when their next Claim opens, what we have verified, and — in plain words — that what a post earns was decided by their post rather than by our queue, when their reply bonus settles, and the most it can pay.

8. How this fits with the rest of the agreement

This Service Commitment is part of the Terms of Service and does not enlarge them. In particular:

• The Service is provided “as is” and “as available”, and the warranty disclaimer and liability cap in the Terms of Service apply to this document as they do to the rest of the agreement. Our total liability for a missed target is limited as set out there.
• The commitments about honoring issued Claims, durable capacity, and wind-down live in the Terms of Service. They are stronger promises than this one and are not limited by it.
• Nothing here changes the reward rules: rewards attach to the disclosed act of posting, never to sentiment, engagement, or outcomes.

We may update this Service Commitment. If we lower a target or narrow a remedy, we will give you at least 30 days notice by email before the change takes effect, and the change never applies retroactively to a Claim already issued.

Contact Us

Questions about this commitment, or reporting something that looks like an outage? Email hello@earnesty.app and check the status page first if you can — it is usually faster than we are.