A missing post on one Mastodon server means that local server has not fetched or indexed that object, not that the account or post is absent from the fediverse. If you have a voluntarily shared exact public object URL, open it while signed in to the server you are checking so the server can attempt to fetch the known remote public object. If it still does not resolve, record the precise limit: the object could not be confirmed from this server, and you stop there.
Find public social profile clues with our TraceSeek app.
What a server actually sees
Mastodon is federated, so no single server holds a complete view of every public account or post. A server only knows some public posts, and there is no shared global timeline state that any one administrator can inspect. When a known remote public URL is searched, the server can fetch that object to its local view. This is discovery, not proof that the wider network contains or lacks anything else. [Mastodon: federated timelines and post interactions]
- Treat what appears on your server as local coverage, not a global census.
- Keep the full public URL intact when checking; the host part alone is not an object address.
Absence is local, not global
If the exact public object URL does not resolve on your server, the supported observation is that this server cannot show it in that attempt. Possible reasons include the server not having fetched the object, the account or post being restricted, or a visibility and authorization rule that filters it. None of those outcomes justify saying the account does not exist or that the post was never made. Write down only the attempt and its local result.
Why a server name in a username is not enough
Retaining the domain from a username tells you where an account is hosted, but it does not carry the address of a particular post. Federated object discovery needs the exact object identifier, not a reconstructed guess. If someone shares only a username or a server domain, you cannot derive the post URL from it, and a confident-looking reconstruction can point at a different object. Ask only for a voluntarily shared public object URL; do not seek private records or try to reach restricted content.
| observation | limit | next step |
|---|---|---|
| The exact public object URL resolves on your server | This proves only that your server can display the object now | Read the object and record the date and server you checked |
| The exact public object URL does not resolve | This is local non-coverage, not global absence | Note the failed attempt and stop; do not infer deletion or nonexistence |
| You have only a username with a server domain | That identifies a host, not a post | Do not invent a post URL; ask for or rely on a voluntarily shared public link |
| The link is ambiguous, mismatched or points to restricted content | The evidence does not support a claim about the account or post | Record the precise limit and make no identity or activity inference |
Separate the observation from the decision
Keep two lines in your notes. The observation line says what you saw: an exact public URL resolved, did not resolve, or was never supplied. The limit line says what that result cannot establish. Keep any decision on a third line, such as pausing a verification task or asking for a public link again. Do not let a missing local result become a statement about the person behind the account, their intent, or their current activity. A badge, matching name, or privacy setting is not proof of identity either.
A hypothetical walkthrough
Imagine a colleague shares an exact public post URL and says it does not show on their Mastodon server. You open the same URL signed in to that server and still see nothing. The careful note is: the server could not confirm this public object during the attempt on that date. It is not: the author deleted the post, the account is gone, or the colleague was blocked. If the colleague later supplies a different public link, treat that as a fresh check with its own observation and limit.
- Write the exact URL and server checked in your notes.
- State the result as local coverage only.
- Stop before inferring deletion, identity, intent or current activity.
When to stop rather than search harder
Stop when the source is absent, private, mismatched or ambiguous. Trying to bypass a restriction, match faces, or identify an owner from a photo goes beyond public-source checking and is not something this worksheet supports. If a public-profile image is the only artifact, public-source image-similarity or OCR search may surface possible public matches, but results are not guaranteed coverage and do not identify a person or prove activity. Treat any AI-generated description of a public profile as a guess unless the profile itself states the claim.
A reader worksheet
Make a short table with three columns: the exact public object URL, the server and date checked, and the local result with its limit. Add a final column for any action, such as asking for a public link again or closing the check. This worksheet is an editorial aid for organizing your own notes; it is not a platform test or a control you can assume exists. Keep it limited to voluntarily shared public material. [Mastodon: federated timelines and post interactions]
A couple more questions
Does a missing post on my Mastodon server mean the account was deleted?
No. It means your server could not show that object in that attempt. The post may exist elsewhere, may be restricted, or may simply not have been fetched locally. Record local non-coverage and avoid claims about deletion or identity.
Can I derive a post URL from a Mastodon username and server?
No. The server domain identifies where an account is hosted, not a specific post. Object discovery needs the exact public object URL, and a reconstructed address can point at something else.
What if the public link is private, mismatched or ambiguous?
Record that precise limit and stop. Do not attempt private-account access, identification from similarity, or inference about intent, relationship status or current activity from the failed check.
Is one successful lookup proof the account is active?
No. It shows your server could display that public object at that moment. It does not prove who owns the account, that the owner is active now, or that any other post exists.
Sources & editorial notes
Official references checked on October 24, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.